So everything in Rawhide must be compiled with -fPIC?

Till Maas opensource at till.name
Fri Feb 20 18:55:48 UTC 2015


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.

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

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

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

> 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?
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
results from other people proposing changes. So what is different here?
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.

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

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

Regards
Till


More information about the devel mailing list