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

From: William Pitcock <[email-masked]>
Date: Wed, 11 Apr 2012 11:16:21 +0000

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:  [email-masked]
Help:         [email-masked]
---

---

From: Kevin Chadwick <[email-masked]>
Date: Wed, 11 Apr 2012 14:17:38 +0100

On Wed, 11 Apr 2012 11:16:21 +0000

>    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.

---

---

From: Kiyoshi Aman <[email-masked]>
Date: Wed, 11 Apr 2012 08:24:36 -0400

> 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.

---

---

From: Kevin Chadwick <[email-masked]>
Date: Wed, 11 Apr 2012 15:18:37 +0100

On Wed, 11 Apr 2012 08:24:36 -0400
Kiyoshi Aman wrote:

> 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?

---

---

From: William Pitcock <[email-masked]>
Date: Wed, 11 Apr 2012 23:27:00 +0000

Hi,

> 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

---

---

From: Dubiousjim <[email-masked]>
Date: Wed, 11 Apr 2012 23:19:43 -0400

On Wed, Apr 11, 2012, at 11:27 PM, William Pitcock wrote:
> ...

Thank you for this detailed explanation.
-- 
[email-masked]

---

---

From: Kevin Chadwick <[email-masked]>
Date: Fri, 13 Apr 2012 13:47:00 +0100

On Wed, 11 Apr 2012 23:27:00 +0000

> 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 ;).

---

---

From: William Pitcock <[email-masked]>
Date: Sat, 14 Apr 2012 00:47:32 +0000

Hi,

> hardly used firefox) and am quite happy. I'll certainly keep an eye on

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

---

---

From: Kevin Chadwick <[email-masked]>
Date: Sat, 14 Apr 2012 16:05:00 +0100

On Sat, 14 Apr 2012 00:47:32 +0000

> 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 ;-). 

---

---

From: Kiyoshi Aman <[email-masked]>
Date: Sat, 14 Apr 2012 11:27:05 -0400

> 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.)

---

---

From: Natanael Copa <[email-masked]>
Date: Fri, 13 Apr 2012 22:52:03 +0200

> 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

---