So everything in Rawhide must be compiled with -fPIC?

[Peter Robinson]

On Fri, Feb 20, 2015 at 6:55 PM, Till Maas <opensource at till.name> wrote:
> On Fri, Feb 20, 2015 at 05:21:59PM +0000, Peter Robinson wrote:
>> >> I've never argumented against the goal that web browser or all network aware
>> >> services should be PIEs, after all, why would we (Ulrich Drepper and myself)
>> >> add the PIE support into the toolchain otherwise?
>> >> I'm just not convinced most of the unpriviledged programs should be PIEs.
>> >
>> > Thanks to e.g. e-mail about any program can be made to run untrusted
>> > data, e.g. PDF readers, office suites, image viewers, if you open an
>> > attachment of the respective type. Therefore it makes a sane default
>> > IMHO. It is also something to attract users that care about security
>> > very much to Fedora.
>>
>> So your saying here that this is miraculously going to stop people
>> from running random binaries that are being emailed to them? Or is
>> just going stop people from running random non PIC/PIE binaries? I
>> don't buy that this is a miracle fix to that problem. How then does it
>> affect other third party binaries not compiled with PIC/PIE that
>> people might wish to run?
>
> No, am am saying I can open PDF documents knowing that I did what I
> could to be secure when open it etc. Also I know that if recommend
> people Fedora and give basic guidelines, that they are as good protected
> as possible.

How is a PDF with a binary payload any different? Sounds like we need
to be running pdf readers in a selinux container?

>> More over in the Change request [1] I don't see any evidence with
>> examples, links to research papers etc on how this makes things more
>> secure.... all I see is basically "because SECURITY man!!!" . The
>> feature says "our users less likely become victims of attacks" but
>> which sort of attacks, how does it improve security. I understand why
>
> There were a lot of details given in several tickets and discussions,
> since this is nothing new. As with other Changes there was a public
> discussion on this list and the FESCo discussions were public as well.

It would be useful to provide those details in the Change for easy
reference to those reading it :-)

>> we'd want it on remotely accessible daemons and long running back
>> ground processes, even things like mail clients that connect to the
>> internet. There is absolutely no technical detail in the change, other
>
> There are already packaging guidelines with clear MUST criteria that are
> not followed and SHOULD criteria that are usually ignored. If you look
> at exploits happening in the Windows world, it is not just things that
> do network communication themselves, but also tools that process data
> that came from the Internet. And if you think about it, there is hardly
> anything that might not process untrusted data.

And if you think about it Fedora is already widely different to the
world of Windows. I'm well aware of the packaging criteria and the
would of network communications, security and even windows.

>> than the technical change to implement it, there's no mention that it
>> will have an impact on performance, with numbers to back it up, across
>> the three primary architectures.
>
> So how much performance impact is acceptable?

Well you've not documented any of the impact so how can we discuss
that? We have no idea if the impact is going to be 0.1% 1% or 10% so
how can the discussion happen without numbers? Numbers speak?

In an uber secure environment if it was going to be 10% they'd likely
just throw more money at it, but 10% in Fedora even people on the
highest spec of hardware would probably complain. I know it's not
going to be that but you as the feature owner haven't presented
anything as yet.

>> Given that the person who actually wrote the code to implement the
>> actual functionality has grave concerns about it's usefulness and
>> impact to end users and packagers. I'm also concerned that he will be
>> the person that will need to fix problems are likely going to be seen
>> by packagers and not you as the person proposing the change? Do you
>> have the time and ability to deal with these problems? Having dealt
>> with these issues across a number of architectures and having had to
>> ask Jakob nicely for his time and assistance when there's been issues
>> from his response I'm not sure you've got his buy in to deal with
>> this.
>
> So because I proposed the change, I will have to do everything alone?

No, you won't be doing the mass rebuild for example. But you do need
to do enough to back up your proposal. Just like the people proposing
gcc5 did a mass rebuild test with details.

> There were already several people that supported this and if there are
> problems, I will deal with them. However, the proposal was accepted and
> I do not see that this is a requirement that other Changes or Features
> needed to fulfill. And I as a package maintainer also do work that

Other Changes or Features don't impact every single package. Those
that do, see the mass rebuild for gcc5 mentioned above, do tend to
have a requirement to back up their changes due to the impact. Others
that impact less but are still widely affecting such as libinput still
have an onus to prove they're not going to widely impact the things
they're changing and provide a fall back for those users affected.
Passing a command line parameter to disable this isn't and option here
so yes, I do believe the onus is on you to prove your change isn't
widely impacting.

> results from other people proposing changes. So what is different here?

The difference here I have mentioned above, it's not a feature you can
easily turn off with a command line option. It affects everyone and
everything in the distro, like gcc5, and they did massive amount of
work with their own mass rebuild to prove the impact.

> I am actually uncomfortable to discuss what Jakub is willing to do.
> Obviously I will ask him for help if needed and from the discussions
> about this Change I made only good experiences, but obviously with all
> volunteer effort in Fedora, I know I cannot demand anything. But I do
> not see much value in discussions ifs and whens, when there are no
> issues.

But you don't know there is no issues. You've not mass rebuilt the
distro or done a minor rebuild of core bits across all architectures
we support (both primary and secondary) and the upstream person that
developed the functionality had expressed concerns with what you are
doing. Those reason alone are why I have concern.

>> Also I've seen no performance analysis across all three architectures
>> to see the impact. I'll happily send you an XO-1 to test on (our
>> lowest supported device on i686 and also one of our most widely
>> deployed Fedora device) and ARM hardware if you've not got access to
>> test.
>
> What do you want to have tested and how much performance impact is
> acceptable? Since we are early in the Fedora 23 development process,
> there is still a lot of time to do tests.

And another mass rebuild? Most major changes have done some impact
testing. Do we even know what percentage of packages will even
actually build when the mass rebuild happens? Nope!

>> Fedora users tend to keep hardware around for longer time than a lot
>> of enterprises, it's also a distro used a lot in the developing world
>> on low end cheap hardware because the rest of the world isn't
>> necessarily so privileged as to be able afford the latest and greatest
>> and I think we need to consider that along side "possible" security
>> improvements!
>
> I know, I bought myself hardware that I cannot use because Fedora ceases
> to support it.

What hardware would that be? You're not going to name it?

Peter