[gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

Hi Diego,

So I recently published this: http://blog.zx2c4.com/749 , a local priv
escalation. It doesn't work on Fedora because their /bin/su is compiled
with -pie. (They don't compile gpasswd with -pie though, so they're still
vulnerable.) In any case, what if we made it a policy in Gentoo to compile *
all* SUID binaries with PIE, to prevent against any types of future attacks
of this variety?

Jason

[-- Attachment #2: Type: text/html, Size: 545 bytes --]

[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

Hello Jason,

Il giorno lun, 23/01/2012 alle 20.08 +0100, Jason A. Donenfeld ha
scritto:

> So I recently published this: http://blog.zx2c4.com/749 , a local priv
> escalation.

I've seen the news :)

>  It doesn't work on Fedora because their /bin/su is compiled with
> -pie. (They don't compile gpasswd with -pie though, so they're still
> vulnerable.)

Is it because of PIE alone or ASLR? Just curious it doesn't make much
difference to me.

> In any case, what if we made it a policy in Gentoo to compile all SUID
> binaries with PIE, to prevent against any types of future attacks of
> this variety?

Here's the trick: it's hard to decide what to compile PIE and what not
because we generally don't split the build for the two. I guess a good
point here could be made to build _everything_ PIE, but it can be tricky
(at least hotot seem not to work on a PIE system).

It would be also a good idea to resume working on the file-based
capabilities, dropping suid altogether.

The main issue here: it's not just my call to make; toolchain and
council should probably chime in on this.

-- 
Diego Elio Pettenò <flameeyes@gentoo.org>
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On Mon, Jan 23, 2012 at 20:22, Diego Elio Pettenò <flameeyes@gentoo.org>wrote:
>
> Is it because of PIE alone or ASLR? Just curious it doesn't make much
> difference to me.
>

When ASLR is turned on, the .text section of executables compiled with PIE
is given a randomized base address. When ASLR is off or when PIE is not
used, the base address is predictable, so it's easy to find where to write
into.


> Here's the trick: it's hard to decide what to compile PIE and what not
> because we generally don't split the build for the two. I guess a good
> point here could be made to build _everything_ PIE, but it can be tricky
> (at least hotot seem not to work on a PIE system).
>

Doesn't portage already have a check on SUID executables where it checks to
see if they meet a certain standard and also strips them of read
capabilities? Couldn't we just add a Q&A blurb to this, so that if any SUID
executables are merged that aren't PIE, there's a nice yellow warning? And
then gradually package maintainers would add the required patches?



It would be also a good idea to resume working on the file-based
> capabilities, dropping suid altogether.
>

Of course. But, different discussion.

[-- Attachment #2: Type: text/html, Size: 1831 bytes --]

[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]

Il giorno lun, 23/01/2012 alle 20.26 +0100, Jason A. Donenfeld ha
scritto:
> When ASLR is turned on, the .text section of executables compiled with
> PIE is given a randomized base address. When ASLR is off or when PIE
> is not used, the base address is predictable, so it's easy to find
> where to write into.

Yup, I know that. I was just making sure that the actual prevention came
from ASLR and not PIE by itself. Both because there is at least one
sci-math package that cannot build with ASLR (randomize_va_space) turned
on, and because it would have disproven my old blog post:

http://blog.flameeyes.eu/2009/11/02/the-pie-is-not-exactly-a-lie


> Doesn't portage already have a check on SUID executables where it
> checks to see if they meet a certain standard and also strips them of
> read capabilities? Couldn't we just add a Q&A blurb to this, so that
> if any SUID executables are merged that aren't PIE, there's a nice
> yellow warning? And then gradually package maintainers would add the
> required patches?

Stripping a compiled file of read permissions is quick, painless and
(mostly) safe from errors. Changing the way it is compiled.. not so
much.

I'm not saying that it's not a good idea, but if we want to proceed with
this, there has to be someone who goes to look at all the packages and
corrects them.

I've not been running the tinderbox for a while both because I have very
little time to _file_ bugs, but more importantly because, being there to
file bugs only, without the time to tackle them, the result was a bunch
of grumpy devs who either needed to repeat the test on a new version, as
the bug became stale, or found me positively annoying as I didn't fix
the stuff myself.

That said, I could fix up the tinderbox and make it run again, no
problem there. I could even try to find the time to look at the logs
and/or see if s3fs allows me to publish them for someone to look through
them... and definitely identifying all the packages installing suid
binaries is easier than looking through all the logs.

But I'd rather not do that unless there is enough consensus that we'll
be tackling the issue.

-- 
Diego Elio Pettenò <flameeyes@gentoo.org>
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

On Mon, Jan 23, 2012 at 20:37, Diego Elio Pettenò <flameeyes@gentoo.org>wrote:
>
> Stripping a compiled file of read permissions is quick, painless and
> (mostly) safe from errors. Changing the way it is compiled.. not so
> much.
>
> I'm not saying that it's not a good idea, but if we want to proceed with
> this, there has to be someone who goes to look at all the packages and
> corrects them.
>
>
Right. It's a big ordeal. I'm *not* suggesting, however, that we
automatically inject a CFLAG or something awful like that.

What I propose is just to *detect* at merge-time whether or not there are
SUID binaries that are not PIE, and if so, spit out a Q&A warning.

That way, package maintainers could fix things up bit by bit, without
having to burden you alone with tinderbox troubles.

[-- Attachment #2: Type: text/html, Size: 1143 bytes --]

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Mike Gilbert]

On Mon, Jan 23, 2012 at 2:40 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> That way, package maintainers could fix things up bit by bit, without having
> to burden you alone with tinderbox troubles.

How do I go about testing with PIE/ASLR on my own box? Is it just some CFLAGS?

A link to some documentation would or just a quick set of instructions
would be great.

[gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

Il giorno lun, 23/01/2012 alle 20.40 +0100, Jason A. Donenfeld ha
scritto:
> What I propose is just to detect at merge-time whether or not there
> are SUID binaries that are not PIE, and if so, spit out a Q&A
> warning.  
> 
> That way, package maintainers could fix things up bit by bit, without
> having to burden you alone with tinderbox troubles. 

The quick answer is: "you can try but it's not going to happen".

It's not something we haven't done before, in relation to suid binaries.
For quite a long time we've had the "immediate binding" warning on suid
binaries built without -Wl,-z,now — it was removed once both uclibc and
glibc took care of forcing immediate bindings at the loader's level for
suid binaries, but we've had packages throwing that warning till the
very last moment.

Even though it was already a warning when _I_ became a dev.

Sigh :)

-- 
Diego Elio Pettenò <flameeyes@gentoo.org>
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

To check for PIE,

readelf -h /bin/su | grep Type

If it says EXEC, no PIE. If it says DYN, yes PIE.

--
sent from my mobile


On 1/23/12, Mike Gilbert <floppym@gentoo.org> wrote:
> On Mon, Jan 23, 2012 at 2:40 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>> That way, package maintainers could fix things up bit by bit, without
>> having
>> to burden you alone with tinderbox troubles.
>
> How do I go about testing with PIE/ASLR on my own box? Is it just some
> CFLAGS?
>
> A link to some documentation would or just a quick set of instructions
> would be great.
>
>

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Mike Gilbert]

On Mon, Jan 23, 2012 at 2:57 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> To check for PIE,
>
> readelf -h /bin/su | grep Type
>
> If it says EXEC, no PIE. If it says DYN, yes PIE.

I'm asking "how does one enable PIE/ASLR", not how to check if it is
enabled already.

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Sven Vermeulen]

On Mon, Jan 23, 2012 at 03:00:41PM -0500, Mike Gilbert wrote:
> I'm asking "how does one enable PIE/ASLR", not how to check if it is
> enabled already.

Look at http://hardened.gentoo.org, the default toolchain used includes PIE,
and it also includes various other measures (like additional grSecurity
restrictions or even SELinux) that makes Gentoo Hardened systems less
vulnerable to this specific vulnerability.

Wkr,
	Sven Vermeulen

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Francesco Riosa]

2012/1/23 Mike Gilbert <floppym@gentoo.org>:
> On Mon, Jan 23, 2012 at 2:57 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>> To check for PIE,
>>
>> readelf -h /bin/su | grep Type
>>
>> If it says EXEC, no PIE. If it says DYN, yes PIE.
>
> I'm asking "how does one enable PIE/ASLR", not how to check if it is
> enabled already.

- PIE should be -fPIC also for the executable, not only for the .so
(has a performance impact)
- ASLR you need "hardened" use for gcc, and the toolchain, pax kernel help too

xattr could be used to reduce the number of suid binaries, but need
support in portage

right?

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Agostino Sarubbo]

[-- Attachment #1.1: Type: text/plain, Size: 555 bytes --]

On Monday 23 January 2012 15:00:41 Mike Gilbert wrote:
> I'm asking "how does one enable PIE/ASLR", not how to check if it is
> enabled already.
Just enable hardened profile that compiles generally with:
-fno-strict-overflow -fPIE -fstack-protector-all

in particular with gcc-hardenednossp you have:
fno-strict-overflow -fPIE

with gcc-hardenednopie you have:
fno-strict-overflow -fstack-protector-all

with gcc-hardenednopiessp you have:
-fno-strict-overflow

-- 
Agostino Sarubbo		ago -at- gentoo.org
Gentoo/AMD64 Arch Security Liaison
GPG: 0x7CD2DC5D

[-- Attachment #1.2: Type: text/html, Size: 3783 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 01/23/2012 07:40 PM, Jason A. Donenfeld wrote:
> 
> What I propose is just to /detect/ at merge-time whether or not
> there are SUID binaries that are not PIE, and if so, spit out a Q&A
> warning.
> 
> That way, package maintainers could fix things up bit by bit,
> without having to burden you alone with tinderbox troubles.

This actually sounds a great idea. It probably worth opening a feature
request for portage using our bugzilla.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJPHcePAAoJEPqDWhW0r/LCGvwP/03SWLvj9L7DzWq4hRyvOFUB
t0ugAPv+D3xT1dyAY6QarPWAMotfPPk2LTSR2y4yvxqt8mYoW0xablTB9S+V5YSn
QbBJOQ+lsWzr0Qv5OcWBWWIeOIdyVfX7eMer9YTD1T+zVVOixU0P9T60zq0F6VmI
7Sk/wmFVmj0Tm3iqS9rWkA6aik5TVTKN4NdjqEoOlyZUqNtdgqnChf3eWlWdK/tK
nctze3JRdQdXVcY4q4JHh+cwR099wBL61BzCB9lrwc0HCfKBU3oKrqU29ZjKsDfQ
xtOgOmh0pCVuPtbHnVHC+YWGmBpoRuExaDa5PMbCCrQPi/bcQioMa6XaVmkJqJ7M
bcj5ArCEuE7+66iUvhjwv2vMyA9Vm5RLCpc7YN7dfLwsT+d/2W6+CtRkr38v+mGd
OcFiCfcw3tPoUvZwL+RrAk1rXb3mL4in3XeKwwshq6VjIajKfX29h99YazeZ1X5N
WErKapz9t6pdEcfurXMZJb2WeLljKHI9DkRcOXvK9mb4dDbKk20+KeQ646N5pJCS
c6pJnoU1R8zXPNeP+xAKvaRslubXNmY6mPfE5Lqmzz0DLYi7BMHjP3Cjx30kc9hz
SwiqoEPSdPE4dzQhqP5EGXZkxgUhCu4IaeCWVCh/sP67QZk8dElBJ9nj14w++Kxr
CGNbH7oBy5y5vNAd+LCr
=glKZ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Zac Medico]

On 01/23/2012 12:12 PM, Francesco Riosa wrote:
> 2012/1/23 Mike Gilbert <floppym@gentoo.org>:
>> On Mon, Jan 23, 2012 at 2:57 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>>> To check for PIE,
>>>
>>> readelf -h /bin/su | grep Type
>>>
>>> If it says EXEC, no PIE. If it says DYN, yes PIE.
>>
>> I'm asking "how does one enable PIE/ASLR", not how to check if it is
>> enabled already.
> 
> - PIE should be -fPIC also for the executable, not only for the .so
> (has a performance impact)
> - ASLR you need "hardened" use for gcc, and the toolchain, pax kernel help too
> 
> xattr could be used to reduce the number of suid binaries, but need
> support in portage

We've got experimental support for FEATURES=xattr since
portage-2.2.0_alpha80. We can include that in the next portage-2.1.x
release.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 777 bytes --]

On Monday 23 January 2012 14:37:40 Diego Elio Pettenò wrote:
> Il giorno lun, 23/01/2012 alle 20.26 +0100, Jason A. Donenfeld ha scritto:
> > When ASLR is turned on, the .text section of executables compiled with
> > PIE is given a randomized base address. When ASLR is off or when PIE
> > is not used, the base address is predictable, so it's easy to find
> > where to write into.
> 
> Yup, I know that. I was just making sure that the actual prevention came
> from ASLR and not PIE by itself. Both because there is at least one
> sci-math package that cannot build with ASLR (randomize_va_space) turned
> on

emacs is known to crap itself when building with ASLR too, and the existing 
workarounds (just like its own build system) tend to be fragile :(
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1232 bytes --]

On Monday 23 January 2012 15:12:47 Francesco Riosa wrote:
> 2012/1/23 Mike Gilbert:
> > On Mon, Jan 23, 2012 at 2:57 PM, Jason A. Donenfeld wrote:
> >> To check for PIE,
> >> 
> >> readelf -h /bin/su | grep Type
> >> 
> >> If it says EXEC, no PIE. If it says DYN, yes PIE.
> > 
> > I'm asking "how does one enable PIE/ASLR", not how to check if it is
> > enabled already.
> 
> - PIE should be -fPIC also for the executable, not only for the .so
> (has a performance impact)

not entirely sure what you're saying here.  i'll clarify in general:
	- build all code going into shared libraries with -fPIC
		(regardless of hardening, this is Gentoo policy today)
	- build code going into executables with -fPIE
		(this is what hardened does, not default Gentoo systems)

you could build all code (including executables) with -fPIC, but that has 
useless overhead compared to -fPIE.  it's small but not insignificant.

> - ASLR you need "hardened" use for gcc, and the toolchain, pax kernel help
> too

the hardened toolchain "helps", but it is not required.  ASLR is in the 
mainline Linux kernel and iirc, enabled by default.  it is already operating 
on all shared libraries because those are PIC.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 715 bytes --]

On Monday 23 January 2012 14:08:51 Jason A. Donenfeld wrote:
> So I recently published this: http://blog.zx2c4.com/749 , a local priv
> escalation. It doesn't work on Fedora because their /bin/su is compiled
> with -pie. (They don't compile gpasswd with -pie though, so they're still
> vulnerable.) In any case, what if we made it a policy in Gentoo to compile
> * all* SUID binaries with PIE, to prevent against any types of future
> attacks of this variety?

pedantically, PIE+ASLR makes it significantly harder to exploit, not impossible

if we could get some general performance numbers that show non-PIE vs PIE, 
that'd help make the case for turning PIE on by default regardless of set*id.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

On Mon, Jan 23, 2012 at 23:18, Zac Medico <zmedico@gentoo.org> wrote:
>
> We've got experimental support for FEATURES=xattr since
> portage-2.2.0_alpha80. We can include that in the next portage-2.1.x
> release.
>

Awesome. If possible though, let's keep the no-SUID-ever discussion for
another thread, as xattr still raises the same point this thread is focused
on: if they're not PIE, they can be easily injected, and their "xattr"s
utilized for nefarious means.


> --
> Thanks,
> Zac
>
>

[-- Attachment #2: Type: text/html, Size: 932 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

On Tue, Jan 24, 2012 at 06:58, Mike Frysinger <vapier@gentoo.org> wrote:
>
> pedantically, PIE+ASLR makes it significantly harder to exploit, not
> impossible
>
> if we could get some general performance numbers that show non-PIE vs PIE,
> that'd help make the case for turning PIE on by default regardless of
> set*id.
>

For starters, though, what about just pooping a Q&A warning for non-PIE
SUID? That way those packages could be fixed, and we'd have a little trial
to see how PIE behaves across different platforms. If that all goes well,
we bump up to default, but that's a far off discussion.



> -mike
>

[-- Attachment #2: Type: text/html, Size: 1060 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 105 bytes --]

I've just been informed that RHEL does not allow non-PIE executables. We
really should follow suit here.

[-- Attachment #2: Type: text/html, Size: 110 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On 1/27/12 8:02 PM, Jason A. Donenfeld wrote:
> I've just been informed that RHEL does not allow non-PIE executables. We
> really should follow suit here.

I'm generally in favor of enabling more hardening features by default
(i.e. reversing the default, so that people who want to disable PIE can
still do it). Note that the hardened profile uses PIE by default iirc.

The most common argument against it is performance loss I think, and
there are probably less than 10 packages that have some compilation
issues with PIE. In my opinion we can deal with that, and security
benefits are much more important.

If the discussion on this doesn't get conclusive, how about adding the
question to the Council's agenda?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 323 bytes --]

On Friday 27 January 2012 14:02:33 Jason A. Donenfeld wrote:
> I've just been informed that RHEL does not allow non-PIE executables. We
> really should follow suit here.

i can't emphasize how little i care what RHEL/Fedora do.  so the logic of 
"they do XXX therefore we should XXX" holds little sway for me.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 826 bytes --]

On Thursday 26 January 2012 11:55:54 Jason A. Donenfeld wrote:
> On Tue, Jan 24, 2012 at 06:58, Mike Frysinger <vapier@gentoo.org> wrote:
> > pedantically, PIE+ASLR makes it significantly harder to exploit, not
> > impossible
> > 
> > if we could get some general performance numbers that show non-PIE vs
> > PIE, that'd help make the case for turning PIE on by default regardless
> > of set*id.
> 
> For starters, though, what about just pooping a Q&A warning for non-PIE
> SUID? That way those packages could be fixed, and we'd have a little trial
> to see how PIE behaves across different platforms. If that all goes well,
> we bump up to default, but that's a far off discussion.

a QA warning doesn't help anyone if we don't have documentation in place 
explaining to people how to do this cleanly
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

On 27-01-2012 20:39:24 +0100, "Paweł Hajdan, Jr." wrote:
> If the discussion on this doesn't get conclusive, how about adding the
> question to the Council's agenda?

Negative from my point of view, this is an issue that the dev-community
can solve themselves without needing a "force" from the Council.

Just implement it in a way that people can opt-in/opt-out on it.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 255 bytes --]

On Friday 27 January 2012 14:39:24 Paweł Hajdan, Jr. wrote:
> If the discussion on this doesn't get conclusive, how about adding the
> question to the Council's agenda?

getting the Council to vote on something without real data is premature
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On 1/27/12 8:45 PM, Fabian Groffen wrote:
> On 27-01-2012 20:39:24 +0100, "Paweł Hajdan, Jr." wrote:
>> If the discussion on this doesn't get conclusive, how about adding the
>> question to the Council's agenda?
> 
> Negative from my point of view, this is an issue that the dev-community
> can solve themselves without needing a "force" from the Council.

That's why I said "if the discussion on this doesn't get conclusive". Of
course it's much better to have a consensus about that, but in some
important cases a tie-breaker can be useful.

> Just implement it in a way that people can opt-in/opt-out on it.

We already have an opt-in (hardened profile), and of course it can be
implemented in a way which allows opt-out (I even mentioned that).

The main point is changing the default.

Another note: "quiet build" default was a part of Council meeting agenda
(<http://www.gentoo.org/proj/en/council/meeting-logs/20111213-summary.txt>),
so it shouldn't be too surprising that a default important for security
is also suggested.

Again - only if we don't get a consensus here.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Rich Freeman]

On Fri, Jan 27, 2012 at 3:13 PM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> On 1/27/12 8:45 PM, Fabian Groffen wrote:
>> Just implement it in a way that people can opt-in/opt-out on it.
>
> We already have an opt-in (hardened profile), and of course it can be
> implemented in a way which allows opt-out (I even mentioned that).
>
> The main point is changing the default.

Well, probably wouldn't hurt to split this out of hardened into
something intermediate first.  You won't get much testing in hardened
on many packages.

I agree that changing the default is the long-term solution.  Default
off to start but have it available on mainstream profiles.  Encourage
people to use it.  Then make it the default but let people opt-out.
Then maybe in the long-term future de-support the opt-out if it seems
prudent.  However, the hardened experience will no doubt help us.

Rich

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

On Fri, Jan 27, 2012 at 20:39, "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org>wrote:
>
> The most common argument against it is performance loss I think, and
> there are probably less than 10 packages that have some compilation
> issues with PIE. In my opinion we can deal with that, and security
> benefits are much more important.


I'm *not* suggesting PIE is enabled by default for all packages. This is a
big job with performance losses, etc. I *am* suggesting that PIE is enabled
for all SUID binaries.

[-- Attachment #2: Type: text/html, Size: 795 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Fri, Jan 27, 2012 at 20:43, Mike Frysinger <vapier@gentoo.org> wrote:
>
> a QA warning doesn't help anyone if we don't have documentation in place
> explaining to people how to do this cleanly


This is very true.


@Flameeyes: Could you advise on the best, cleanest way to do this? What
should the general instruction be?

[-- Attachment #2: Type: text/html, Size: 624 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 227 bytes --]

On Fri, Jan 27, 2012 at 21:13, "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org>wrote:
>
> Again - only if we don't get a consensus here.
>
>
Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
binaries*?

[-- Attachment #2: Type: text/html, Size: 503 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Anthony G. Basile]

On 01/27/2012 02:39 PM, "Paweł Hajdan, Jr." wrote:
> On 1/27/12 8:02 PM, Jason A. Donenfeld wrote:
>> I've just been informed that RHEL does not allow non-PIE executables. We
>> really should follow suit here.
> I'm generally in favor of enabling more hardening features by default
> (i.e. reversing the default, so that people who want to disable PIE can
> still do it). Note that the hardened profile uses PIE by default iirc.

Exactly.  Jason, if you want PIE across the board (with a few 
exceptions), switch to hardened.

>
> The most common argument against it is performance loss I think, and
> there are probably less than 10 packages that have some compilation
> issues with PIE. In my opinion we can deal with that, and security
> benefits are much more important.
>
> If the discussion on this doesn't get conclusive, how about adding the
> question to the Council's agenda?
>

I'm trying to measure the perf difference on amd64 even as I type this.  
With nbench I'm only seeing about a 4% hit with PIE.  I'm going to try 
to narrow it down to some POC code that you can play with.  Mostly the 
hit comes on setting up call stacks because of the extra machinery in 
PIE.  When I've investigated further I'll let the list know.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 640 bytes --]

On Friday 27 January 2012 16:05:13 Jason A. Donenfeld wrote:
> On Fri, Jan 27, 2012 at 21:13, "Paweł Hajdan, Jr." wrote:
> > Again - only if we don't get a consensus here.
> 
> Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
> binaries*?

he was talking system wide

considering the number set*id binaries in the tree, and their requirements 
(they tend to not be performance sensitive in the slightest), i don't have a 
problem with steering them in the PIE direction.

ignoring /usr/bin/Xorg here of course, but that has a lot more problems that i 
doubt PIE will make much of a difference.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On Sat, Jan 28, 2012 at 01:01, Anthony G. Basile <blueness@gentoo.org>wrote:
>
>
> Exactly.  Jason, if you want PIE across the board (with a few exceptions),
> switch to hardened.
>
>
What? Are you kidding?

Again, to reiterate, *I AM NOT SUGGESTING HAVING PIE ACROSS THE BOARD.*

What I suggest is that we have PIE for SUID executable. See the subject of
this thread.

[-- Attachment #2: Type: text/html, Size: 721 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On Sat, Jan 28, 2012 at 01:12, Mike Frysinger <vapier@gentoo.org> wrote:
>
> > Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
> > binaries*?
>
> he was talking system wide
>

This thread is about PIE on SUID executables.


>
> considering the number set*id binaries in the tree, and their requirements
> (they tend to not be performance sensitive in the slightest), i don't have
> a
> problem with steering them in the PIE direction.
>

Great!


>
> ignoring /usr/bin/Xorg here of course, but that has a lot more problems
> that i
> doubt PIE will make much of a difference.
>

Oh boy. Yea. Oh boy. Xorg should be PIE too, I suppose. Only takes
one rotten egg.



> -mike
>

[-- Attachment #2: Type: text/html, Size: 1457 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Anthony G. Basile]

On 01/27/2012 07:12 PM, Mike Frysinger wrote:
> On Friday 27 January 2012 16:05:13 Jason A. Donenfeld wrote:
>> On Fri, Jan 27, 2012 at 21:13, "Paweł Hajdan, Jr." wrote:
>>> Again - only if we don't get a consensus here.
>> Wait... Is anybody here *actually opposed* to not enabling PIE on *SUID
>> binaries*?
> he was talking system wide
>
> considering the number set*id binaries in the tree, and their requirements
> (they tend to not be performance sensitive in the slightest), i don't have a
> problem with steering them in the PIE direction.
>
> ignoring /usr/bin/Xorg here of course, but that has a lot more problems that i
> doubt PIE will make much of a difference.
> -mike

I've run nbench on two amd64 systems both running the same kernel 
vanilla-3.2.2.  They only differed in that one uses the hardened 
toolchain and the other with a vanilla toolchain.  nbench itself was 
compile pie on the former and no-pie on the later.  I found negligible 
difference in performance.

So at least on amd64, I don't think that performance is ever an issue.  
I have yet to look at x86.


Below I give more info.


Here's the result for the hardened system.

# time -p /usr/bin/nbench

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                     :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1172.2  :      30.06  :       9.87
STRING SORT         :          533.16  :     238.23  :      36.87
BITFIELD            :      5.0544e+08  :      86.70  :      18.11
FP EMULATION        :          150.32  :      72.13  :      16.64
FOURIER             :           30498  :      34.69  :      19.48
ASSIGNMENT          :          35.543  :     135.25  :      35.08
IDEA                :            8060  :     123.28  :      36.60
HUFFMAN             :          2549.8  :      70.71  :      22.58
NEURAL NET          :          58.377  :      93.78  :      39.45
LU DECOMPOSITION    :          1909.8  :      98.94  :      71.44
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 91.279
FLOATING-POINT INDEX: 68.525
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 8 CPU GenuineIntel Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 2673MHz
L2 Cache            : 8192 KB
OS                  : Linux 3.2.2
C compiler          : x86_64-pc-linux-gnu-gcc
libc                :
MEMORY INDEX        : 28.613
INTEGER INDEX       : 19.197
FLOATING-POINT INDEX: 38.007
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.
real 252.44
user 252.26
sys 0.01



Here's the result for the vanilla system

  # time -p /usr/bin/nbench

BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)

TEST                : Iterations/sec.  : Old Index   : New Index
                     :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          1179.4  :      30.25  :       9.93
STRING SORT         :          540.12  :     241.34  :      37.36
BITFIELD            :      5.0565e+08  :      86.74  :      18.12
FP EMULATION        :          164.64  :      79.00  :      18.23
FOURIER             :           30785  :      35.01  :      19.66
ASSIGNMENT          :          35.677  :     135.76  :      35.21
IDEA                :          7984.8  :     122.13  :      36.26
HUFFMAN             :            2686  :      74.48  :      23.78
NEURAL NET          :          57.097  :      91.72  :      38.58
LU DECOMPOSITION    :          1887.4  :      97.78  :      70.60
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 93.349
FLOATING-POINT INDEX: 67.966
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU                 : 8 CPU GenuineIntel Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz 2673MHz
L2 Cache            : 8192 KB
OS                  : Linux 3.2.2
C compiler          : x86_64-pc-linux-gnu-gcc
libc                :
MEMORY INDEX        : 28.777
INTEGER INDEX       : 19.879
FLOATING-POINT INDEX: 37.696
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.
real 252.37
user 252.19
sys 0.01


The CPU is an 8 core i7

processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 26
model name	: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
stepping	: 5
microcode	: 0xb
cpu MHz		: 2673.112
cache size	: 8192 KB
physical id	: 0
siblings	: 8
core id		: 3
cpu cores	: 4
apicid		: 7
initial apicid	: 7
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 5344.67
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:




-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 792 bytes --]

On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
> I've run nbench on two amd64 systems both running the same kernel
> vanilla-3.2.2.

i don't think nbench is a good benchmark for this as it isn't really testing 
what you think it's testing.  it's very good at validating math support in the 
ISA/ABI, optimized compiler output, and supplementary math implementations in 
libgcc.  PIE vs non-PIE will still be able to multiply/divide in pretty much 
the same amount of time.

> So at least on amd64, I don't think that performance is ever an issue.

yes, most likely on systems where the PIC has hardware support in the ISA, the 
performance hit on PIE is typically low.

> I have yet to look at x86.

pretty sure this is going to be much more palpable.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 379 bytes --]

On Saturday 28 January 2012 00:07:01 Jason A. Donenfeld wrote:
> On Sat, Jan 28, 2012 at 01:01, Anthony G. Basile <blueness@gentoo.org>wrote:
> > Exactly.  Jason, if you want PIE across the board (with a few
> > exceptions), switch to hardened.
> 
> What? Are you kidding?
> 
> Again, to reiterate, *I AM NOT SUGGESTING HAVING PIE ACROSS THE BOARD.*

chill dude
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Anthony G. Basile]

On 01/29/2012 02:14 PM, Mike Frysinger wrote:
> On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
>> I've run nbench on two amd64 systems both running the same kernel
>> vanilla-3.2.2.
> i don't think nbench is a good benchmark for this as it isn't really testing
> what you think it's testing.  it's very good at validating math support in the
> ISA/ABI, optimized compiler output, and supplementary math implementations in
> libgcc.  PIE vs non-PIE will still be able to multiply/divide in pretty much
> the same amount of time.

I know, but the problem is, what benchmark best approximates common 
every day use?  So I wrote the following which really hits the problem 
hard on x86:

int modfac(int n)
{
     if(n==0) return 1;
     return n * modfac(n-1);
}

int main()
{
     int i;
     for( i = 0 ; i < 4096*4096 ; i++ ) modfac(4096);
     return 0;
}

Using vanilla kernel 3.2.2, userland built with vanilla toolchain, 
gcc-4.5.3-r1, glibc-2.13-r4, binutils-2.21.1-r1, compiling my code 
simply as gcc -o test modfac.c, CFLAGS="-O2 -march=i686 -pipe" I get:

  time -p ./test
real 327.89
user 327.72
sys 0.00

Keep everything else the same, even the same hardware, but switch to 
userland built with hardened gcc-4.5.3-r2 (not -r1 because of the bus 
error), I get:

  time -p ./test
real 629.68
user 629.37
sys 0.00

The hardware is 8 x "Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz" with 12 GB 
ram.  That's nearly a factor of 2x but how often does one set up 4k 
stack frames in everyday use?

>> So at least on amd64, I don't think that performance is ever an issue.
> yes, most likely on systems where the PIC has hardware support in the ISA, the
> performance hit on PIE is typically low.
>
>> I have yet to look at x86.
> pretty sure this is going to be much more palpable.
> -mike


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

On Tue, 31 Jan 2012 19:58:32 -0500
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> On 01/29/2012 02:14 PM, Mike Frysinger wrote:
> > On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
> >> I've run nbench on two amd64 systems both running the same kernel
> >> vanilla-3.2.2.
> > i don't think nbench is a good benchmark for this as it isn't
> > really testing what you think it's testing.  it's very good at
> > validating math support in the ISA/ABI, optimized compiler output,
> > and supplementary math implementations in libgcc.  PIE vs non-PIE
> > will still be able to multiply/divide in pretty much the same
> > amount of time.
> 
> I know, but the problem is, what benchmark best approximates common 
> every day use?  So I wrote the following which really hits the
> problem hard on x86:
> 
> int modfac(int n)
> {
>      if(n==0) return 1;
>      return n * modfac(n-1);
> }
> 
> int main()
> {
>      int i;
>      for( i = 0 ; i < 4096*4096 ; i++ ) modfac(4096);
>      return 0;
> }
> 
> Using vanilla kernel 3.2.2, userland built with vanilla toolchain, 
> gcc-4.5.3-r1, glibc-2.13-r4, binutils-2.21.1-r1, compiling my code 
> simply as gcc -o test modfac.c, CFLAGS="-O2 -march=i686 -pipe" I get:
> 
>   time -p ./test
> real 327.89
> user 327.72
> sys 0.00
> 
> Keep everything else the same, even the same hardware, but switch to 
> userland built with hardened gcc-4.5.3-r2 (not -r1 because of the bus 
> error), I get:
> 
>   time -p ./test
> real 629.68
> user 629.37
> sys 0.00
> 
> The hardware is 8 x "Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz" with 12
> GB ram.  That's nearly a factor of 2x but how often does one set up
> 4k stack frames in everyday use?
> 
> >> So at least on amd64, I don't think that performance is ever an
> >> issue.
> > yes, most likely on systems where the PIC has hardware support in
> > the ISA, the performance hit on PIE is typically low.
> >
> >> I have yet to look at x86.
> > pretty sure this is going to be much more palpable.
> > -mike
> 
> 

Vanilla userland is simply a stage3 chroot amd64.

hardened kernel/userland
real    5m43.402s
user    5m42.510s
sys     0m0.002s

hardened kernel/vanilla gcc
real    5m29.271s
user    5m28.417s
sys     0m0.003s

hardened kernel/vanilla userland
real    5m29.495s
user    5m28.599s
sys     0m0.030s

vanilla all (disabled pax and grsec on hardened kernel, compiled kernel
with hardened gcc)
real    5m34.861s
user    5m33.981s
sys     0m0.001s

i686 cflag test, vanilla all
	CFLAGS="-O2 -march=i686 -pipe"
	gcc modfac.c -o vv-moddfac
real	5m42.171s
user	5m41.176s
sys	0m0.092s

CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
RAM: 16G


-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1851 bytes --]

On Tuesday 31 January 2012 19:58:32 Anthony G. Basile wrote:
> On 01/29/2012 02:14 PM, Mike Frysinger wrote:
> > On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
> >> I've run nbench on two amd64 systems both running the same kernel
> >> vanilla-3.2.2.
> > 
> > i don't think nbench is a good benchmark for this as it isn't really
> > testing what you think it's testing.  it's very good at validating math
> > support in the ISA/ABI, optimized compiler output, and supplementary
> > math implementations in libgcc.  PIE vs non-PIE will still be able to
> > multiply/divide in pretty much the same amount of time.
> 
> I know, but the problem is, what benchmark best approximates common
> every day use?  So I wrote the following which really hits the problem
> hard on x86:
> 
> int modfac(int n)
> {
>      if(n==0) return 1;
>      return n * modfac(n-1);
> }
> 
> int main()
> {
>      int i;
>      for( i = 0 ; i < 4096*4096 ; i++ ) modfac(4096);
>      return 0;
> }
> 
> Using vanilla kernel 3.2.2, userland built with vanilla toolchain,
> gcc-4.5.3-r1, glibc-2.13-r4, binutils-2.21.1-r1, compiling my code
> simply as gcc -o test modfac.c, CFLAGS="-O2 -march=i686 -pipe" I get:
> 
>   time -p ./test
> real 327.89
> user 327.72
> sys 0.00
> 
> Keep everything else the same, even the same hardware, but switch to
> userland built with hardened gcc-4.5.3-r2 (not -r1 because of the bus
> error), I get:
> 
>   time -p ./test
> real 629.68
> user 629.37
> sys 0.00
> 
> The hardware is 8 x "Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz" with 12 GB
> ram.  That's nearly a factor of 2x but how often does one set up 4k
> stack frames in everyday use?

you mean how often do people do recursion on data sets ?  is that 2x slow down 
really because of the *depth* of the stack ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]