For discussion of Alpine Linux development and developer support

10 5

[alpine-devel] [announce] Sonnet GNU/Linux (somewhat derivative of Alpine)

William Pitcock
Details
Message ID
<CA+T2pCEvey5ztLcjgJAi3aTXLrQz4O3DNiUk5P8C=FVVCGumwg@mail.gmail.com>
Sender timestamp
1334142981
DKIM signature
missing
Download raw message
Hi,

As a side project, I have been building a GNU/Linux distribution based
ontop of some of the components of Alpine (alpine-conf, apk-tools).
It is based on glibc 2.15 and systemd, so administration is comparable
to a Debian wheezy system with systemd-sysv installed.

The code (including a fully cross-compatible systemd packaging for
both Alpine and Sonnet with full modloop compatibility) is available
here:

   http://github.com/sonnet-linux

A simple website containing information about the distribution can be
found here:

   http://sonnet.dereferenced.org/

Right now I am targeting only the x86_64 architecture.  x86 will come
next weekend once we get everything stabilized.

This is a very early stage distribution, many branding changes are
needed still.  I intend to merge some work into aports/alpine-conf to
make rebranding of derivatives easier.  I also have work in that
specific aports tree that enables one to build the distribution with
glibc or uclibc by using a single environment variable, which will
also be merged shortly.

If hacking on a GNU/Linux desktop-optimized distribution built ontop
of parts of Alpine interests you, then download an ISO and start
sending me pull requests.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Kiyoshi Aman
Details
Message ID
<CAML-UdtXXNx83NHWu7v8jm2g2mxPpPgvcubezo_VL7BtUuLW5Q@mail.gmail.com>
In-Reply-To
<965117.94628.bm@smtp142.mail.ukl.yahoo.com> (view parent)
Sender timestamp
1334147076
DKIM signature
missing
Download raw message
On Wed, Apr 11, 2012 at 09:17, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> Any plans for a grsecurity/pax enabled kernel?

As I understand it, PaX and grsec are both pretty worthless for
security; William will most certainly be able to elucidate on that,
but it basically boils down to the specific modifications that these
two patch-sets make to the kernel being irrelevant or useless at best.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Kevin Chadwick
Details
Message ID
<965117.94628.bm@smtp142.mail.ukl.yahoo.com>
In-Reply-To
<CA+T2pCEvey5ztLcjgJAi3aTXLrQz4O3DNiUk5P8C=FVVCGumwg@mail.gmail.com> (view parent)
Sender timestamp
1334150258
DKIM signature
missing
Download raw message
On Wed, 11 Apr 2012 11:16:21 +0000
William Pitcock wrote:

> A simple website containing information about the distribution can be
> found here:
> 
>    http://sonnet.dereferenced.org/

Any plans for a grsecurity/pax enabled kernel?

I jumped to arch for desktops basically for glibc/flash (sandboxed in a
hardly used firefox) and am quite happy. I'll certainly keep an eye on
it though.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Kevin Chadwick
Details
Message ID
<148752.52050.bm@smtp133.mail.ukl.yahoo.com>
In-Reply-To
<CAML-UdtXXNx83NHWu7v8jm2g2mxPpPgvcubezo_VL7BtUuLW5Q@mail.gmail.com> (view parent)
Sender timestamp
1334153917
DKIM signature
missing
Download raw message
On Wed, 11 Apr 2012 08:24:36 -0400
Kiyoshi Aman wrote:

> > Any plans for a grsecurity/pax enabled kernel?  
> 
> As I understand it, PaX and grsec are both pretty worthless for
> security;

As I understand it, PAX and grsec make many known exploits fail. What
grounds are you arguing this on. The fact mprotect is often disabled?


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Dubiousjim
Details
Message ID
<1334200783.28154.140661061298453.0B5FBB22@webmail.messagingengine.com>
In-Reply-To
<CA+T2pCH751w58S9hXB7CyTWEY1_aD3CV4qiswDT8M9OiUsDZxw@mail.gmail.com> (view parent)
Sender timestamp
1334200783
DKIM signature
missing
Download raw message
On Wed, Apr 11, 2012, at 11:27 PM, William Pitcock wrote:
> 
> This is false.  The fact that the distribution is compiled with PIE is
> why many known exploits fail.  The fact that binaries are compiled
> with PIE allows the ASLR code (either in Linux itself or provided by
> PaX) to randomize specific segment addresses in a binary.  ASLR is the
> reason why ret2libc attacks are not successful.
> ...

Thank you for this detailed explanation.
-- 
dubiousjim@gmail.com



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCH751w58S9hXB7CyTWEY1_aD3CV4qiswDT8M9OiUsDZxw@mail.gmail.com>
In-Reply-To
<148752.52050.bm@smtp133.mail.ukl.yahoo.com> (view parent)
Sender timestamp
1334186820
DKIM signature
missing
Download raw message
Hi,

On Wed, Apr 11, 2012 at 2:18 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> On Wed, 11 Apr 2012 08:24:36 -0400
> Kiyoshi Aman wrote:
>
>> > Any plans for a grsecurity/pax enabled kernel?
>>
>> As I understand it, PaX and grsec are both pretty worthless for
>> security;
>
> As I understand it, PAX and grsec make many known exploits fail. What
> grounds are you arguing this on. The fact mprotect is often disabled?

This is false.  The fact that the distribution is compiled with PIE is
why many known exploits fail.  The fact that binaries are compiled
with PIE allows the ASLR code (either in Linux itself or provided by
PaX) to randomize specific segment addresses in a binary.  ASLR is the
reason why ret2libc attacks are not successful.

Now for a discussion about PaX mprotect.  PaX mprotect contains two
somewhat-related components:

- hardening mprotect() to enforce W^X policy:

This part is actually somewhat useful: it ensures that badly written
programs do not successfully request mprotect(..., PROT_WRITE |
PROT_EXECUTE) by ensuring that PROT_EXECUTE is dropped or forbidden by
mprotect() with errno=EPERM.  However, this part can be easily written
in a way where it is suitable for inclusion in the mainstream kernel
and is very trivial to write.  It also ensures that the stack can
never be PROT_EXECUTE as a side-effect, also useful except in cases of
trampoline, where you have programs with PT_GNU_STACK marking or PaX
equivilant.

However, there is a better approach to handling W^X, which is just to
automatically drop PROT_EXECUTE anytime PROT_WRITE is requested (and
also the reverse).  This provides the same security and is more
compatible with virtual machines like Jaegermonkey, V8 and luajit.
This is the approach as taken by OpenBSD, and coincidentally is
partially implemented in modern Linux kernels.  Some further
protection by default is desirable here, but not really important in
terms of defeating vulnerabilities.

- using the CS register to emulate an NX-bit on legacy x86 platforms:

This part is entirely worthless, defeating the NX-bit emulation is
trivial if you know what you're doing due to the limitations in the
way the CS register works.  To put it simply, the CS register defines
the highest possible address of executable code.  In other words, it
should always be higher than ELF_LOAD_BASE, and should always be the
size of .text.

However, when you need mprotect(..., PROT_EXECUTE) then the CS
register has to be modified to point to the end of your memory mapping
you're marking PROT_EXECUTE.  When *that* happens, everything between
ELF_LOAD_BASE and the end of your PROT_EXECUTE mapping is now
executable, including any mappings that lay before it.  ASLR helps
against this a little, because mmap() mappings are at randomized
addresses, but in reality with the CS segment, the ASLR actually makes
this worse.

Regarding ASLR itself, I suspect PaX ASLR to be actually more weak
than the default Linux ASLR with randomize_va_space=2.  Thusly,
there's not really any benefit to using PaX.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Kevin Chadwick
Details
Message ID
<681852.72532.bm@smtp106.mail.ukl.yahoo.com>
In-Reply-To
<CA+T2pCH751w58S9hXB7CyTWEY1_aD3CV4qiswDT8M9OiUsDZxw@mail.gmail.com> (view parent)
Sender timestamp
1334321220
DKIM signature
missing
Download raw message
On Wed, 11 Apr 2012 23:27:00 +0000
William Pitcock wrote:

> > As I understand it, PAX and grsec make many known exploits fail. What
> > grounds are you arguing this on. The fact mprotect is often disabled?  
> 
> This is false.  The fact that the distribution is compiled with PIE is
> why many known exploits fail. The fact that binaries are compiled
> with PIE allows the ASLR code (either in Linux itself or provided by
> PaX) to randomize specific segment addresses in a binary.  ASLR is the
> reason why ret2libc attacks are not successful.


 I suggest you take these things up with the pax team and
spender. From what I've seen, the CONFIG options of grsec and PAX
prevent exploits. I am really surprised there are so many using
grsecurity and no distro anymore with a grsec enabled kernel.



Excerpt from a response by the pax team on the gentoo hardened list for
CVE-2012-0056.
_________________________________________________________________________________

> BTW this in "vanilla" gentoo does not work because of the permission of the su 
> file:
> ls -l /usr/bin/su
> -rws--x--x 1 root root 36776 18 gen 21.31 /usr/bin/su
> 
> readelf cannot read the address, but there can be other ways to access the 
> binary for example for group "disk"  

http://seclists.org/fulldisclosure/2012/Jan/396

> hardened gentoo is un-affected as expected (but you already know)  

this is not quite true, what could work against grsec is an exploit that
implemented a ret2libc style exploit coupled with bruteforcing (if the
target suid is a PIE). 
^^^^^^^^^^^^^^^^^^^^^

i hope you're all enabling the bruteforce protection feature in
grsec ;).


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20120413225203.59a84323@alpinelinux.org>
In-Reply-To
<CA+T2pCEvey5ztLcjgJAi3aTXLrQz4O3DNiUk5P8C=FVVCGumwg@mail.gmail.com> (view parent)
Sender timestamp
1334350323
DKIM signature
missing
Download raw message
On Wed, 11 Apr 2012 11:16:21 +0000
William Pitcock <nenolod@dereferenced.org> wrote:

> Hi,
> 
> As a side project, I have been building a GNU/Linux distribution based
> ontop of some of the components of Alpine (alpine-conf, apk-tools).
> It is based on glibc 2.15 and systemd, so administration is comparable
> to a Debian wheezy system with systemd-sysv installed.

The first Alpine Linux derivative. Very cool!

I would be interested in how it compares to Alpine in terms of boot up
speed, size differences and performance differences. I suppose that
will have to wait til things have stabilized a bit.

Thanks!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
William Pitcock
Details
Message ID
<CA+T2pCG3jRms9ZV8xQeOjg7Zoh4eHp5SZLWJ3tqEGvJAVwPZ-A@mail.gmail.com>
In-Reply-To
<965117.94628.bm@smtp142.mail.ukl.yahoo.com> (view parent)
Sender timestamp
1334364452
DKIM signature
missing
Download raw message
Hi,

On Wed, Apr 11, 2012 at 1:17 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> On Wed, 11 Apr 2012 11:16:21 +0000
> William Pitcock wrote:
>
>> A simple website containing information about the distribution can be
>> found here:
>>
>>    http://sonnet.dereferenced.org/
>
> Any plans for a grsecurity/pax enabled kernel?
>
> I jumped to arch for desktops basically for glibc/flash (sandboxed in a
> hardly used firefox) and am quite happy. I'll certainly keep an eye on
> it though.

I forgot to answer this question, because I got caught up in the other
conversation.

Yes -- we plan on retaining support for grsecurity/pax kernels, but
they will kind of be considered for use by people who know the
implications of their kernel choice.  Meaning that they won't be
necessarily a configuration that is recommended for use by most users
as PAX can introduce problems for desktop users.

I still feel that OpenBSD-style W^X is sufficient though, and could
probably be upstreamed fairly easily.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Kiyoshi Aman
Details
Message ID
<CAML-UdvUr7fXEHqwRpN53M9AJ2BhQZVK7BRYxakPm1_jrC0rjA@mail.gmail.com>
In-Reply-To
<346105.2723.bm@smtp139.mail.ukl.yahoo.com> (view parent)
Sender timestamp
1334417225
DKIM signature
missing
Download raw message
On Sat, Apr 14, 2012 at 11:05, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:
> I've heard some say arch linux is the new contender beating slackware
> as the linux with the most bsdisms. Maybe there's now one more
> contender for that spot? Of course with linux being the kernel, that
> doesn't make any sense as a sentence ;-).

Arch is the new Gentoo. Complete with most of the Gentoobies migrating
over to it from Gentoo, as a matter of fact. (And AUR is a sick,
*sick* joke.)


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Kevin Chadwick
Details
Message ID
<346105.2723.bm@smtp139.mail.ukl.yahoo.com>
In-Reply-To
<CA+T2pCG3jRms9ZV8xQeOjg7Zoh4eHp5SZLWJ3tqEGvJAVwPZ-A@mail.gmail.com> (view parent)
Sender timestamp
1334415900
DKIM signature
missing
Download raw message
On Sat, 14 Apr 2012 00:47:32 +0000
William Pitcock wrote:

> Yes -- we plan on retaining support for grsecurity/pax kernels, but
> they will kind of be considered for use by people who know the
> implications of their kernel choice.  Meaning that they won't be
> necessarily a configuration that is recommended for use by most users
> as PAX can introduce problems for desktop users.
> 
> I still feel that OpenBSD-style W^X is sufficient though, and could
> probably be upstreamed fairly easily.

Your singing to me now :-). That's fair enough, I think a lot of the
parts of grsecurity/PAX could happily live upstream too, but I think
anyone would have a job and a half getting them in.

OpenBSD is my favourite OS. Unfortunately as I don't maintain a huge
number of machines, keeping the OpenBSD desktops updated wasn't really
the best use of my time and the lag (though small) for updates to
firefox and firefox using it's own malloc etc., kinda sealed the deal
for me.

I've heard some say arch linux is the new contender beating slackware
as the linux with the most bsdisms. Maybe there's now one more
contender for that spot? Of course with linux being the kernel, that
doesn't make any sense as a sentence ;-). 


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---