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

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

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.

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

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.

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?

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?

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

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

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