fesco

Clone
Source Code
GIT

#563 suggested policy: all daemons must set RELRO and PIE flags
Closed None Opened 13 years ago by adamwill.

Closed
Reopen Issue

= Proposal topic =

This proposal is to add a requirement that daemons must set some security-related compile-time flags.

= Overview =

Steve Grubb contacted me to ask why no-one had been 'checking' that daemons in Fedora set the RELRO and PIE flags at compile time; he says several do not have these flags set in F14. I explained that this is (as far as I know) not currently a requirement for Fedora packages, so it's not something that is 'checked'. Steve says there are security benefits to using these flags for long-running executables; they are required to be used for daemons in Red Hat Enterprise, and it seems reasonable to consider the same policy for Fedora.

= Problem space =

This is an attempt to improve the security of daemons in Fedora against unknown attacks.

= Solution Overview =

These flags should be passed to gcc and ld at compile time, AIUI. Obviously, where appropriate, patches to do so should be sent upstream. As to what they do, Steve explains:

"PIE (Position Independent Executable) will cause the apps addresses to be randomized every time it starts up. This will help prevent known address attacks. RELRO causes the jump tables and relocation addresses to become readonly. Because the addresses can be randomized for PIE, there are tables that maps everything to its new address and this has to be writable when the program starts up. An attacker can potentially change these addresses to point to malicious code unless its made readonly. So, we want PIE and at least partial RELRO on all daemons. There is a performance penalty for being PIE wrt startup time. So, this is only suitable for long running programs."

Debian documents these as available hardening options but AFAICT doesn't hard require their use in any case. For relro they note "Known problems: (Common build failures, non-availability on some archs)" and for pie they note "This is especially difficult to plumb into packaging in a safe way, since it requires the executable be built with -fPIE for any .o files that are linked at the end with -pie. There is some amount of performance loss, but only due to the -fPIE, which is already true for all the linked libraries (via their -fPIC)."

= Active Ingredients =

This affects packages containing daemons, and of course the maintainers of those packages. Specifically, Steve identified these packages as lacking the flags in F14:

Need RELRO: crond, init, mingetty, rsyslog, udevd, xinetd
Need PIE: init, mingetty, udevd, rsyslog

= Owners =

Adam Williamson (adamwill) and Steve Grubb (sgrubb at redhat).

adding meeting keyword.

kylem is going to talk to various tools folks and gather info for us.
We discussed perhaps making this default in f16 depending on the tradeoffs.

I am +1 for this. Since its done in REL and will improve security its a no brainer IMO

SMP

+1

Replying to [ticket:563 adamwill]:

Steve Grubb contacted me to ask why no-one had been 'checking' [...]

Slightly curious; isn't he a member of the sec team that should be checking this, if anybody ?

Anyway, it sounds reasonable, and also sounds like a 'package quality' thing that autoqa could nicely check for ?

For more information on the benefits of this for DSOs and such, see section 6 in http://people.redhat.com/drepper/nonselsec.pdf

mclasen: "Slightly curious; isn't he a member of the sec team that should be checking this, if anybody ?"

I think he does, for RHEL - this is why he noticed, because he was checking RHEL and saw that things were coming from Fedora which did not use these flags. It's not part of his responsibility to do it for Fedora, though. I think he mailed me just because he figured that as QA I'd know whether it was something we checked or not.

I'm wondering whether the mentioned daemons are really all or just some, because there are many more daemons in Fedora and I can't believe that it's just that less...

We are going to look at if we can just enable this globally in f16 and revisit next week with more input from tools folks.

Kyle is doing some benchmarking and will update this ticket in the next few days.

Will revisit next week.

I wonder what's the question here. It was good for RHEL to be added in mentioned services. So, are we discussing which other services should use relro and pie or whether it is okay for Fedora? I suppose security guys know what they are doing.

Well, I guess the questions are now:

  • Should we just add both or one or the other to default Fedora CFLAGS for f16?
    (ie, build everything with both or either one)

  • If we don't make both of them default due to performance reasons, we should have a way and a guideline for maintainers to note that they should enable them for their package (ie, network facing daemon, large gui, etc).

All that was requested was the flags be added for all daemons (including non-network facing) and all apps that run with privilege such as setuid or file system based capabilities. That's all the request is. In my opinion, this should have made it in time for F15. I didn't ask for an expanded scope.

Sure. The issues I have with just saying "all daemons" are:

  • it's not clear to maintainers if this applies to them. Many won't realize it unless someone generates a list and files bugs from time to time. New packages won't have this happen sometimes until some one notices it needs it, etc.

  • This could have advantages for the entire distro/all packages, and if the performance hit isn't significant, why not take advantage of it?

Hey, are we talking about enabling partial or full relro in default flags here? Partial relro (-Wl,-z,relro) should be safe to enable globally (I think some other distros already do this). Full relro (-Wl,-z,relro,-z,now) has more startup cost, but makes the entire GOT read-only, which makes certain types of vulnerabilities harder to exploit. I think full relro is especially worthwhile on long-running processes, where you don't have to pay this cost very often.

PIE definitely should be limited only to security relevant apps
- suid or otherwise elevated priviledges, network facing daemons,
apps with very high number of security issues (like e.g. firefox)).
While the runtime cost of PIE is smaller on x86_64 compared to i686
as you don't lose one extra register and don't need to setup PIC pointer
in most of the routines, it is still very significant (extra indirection
for many variable accesses). Furthermore, PIEs aren't prelinkable, so
you will loose up to half a second or so on startup of larger apps.
So I'm strongly against forcing it to all or most executables.

Similarly for -Wl,-z,now.

As of today's fesco meeting, nirik to draft guidelines for packages where -fPIE and -z now are recommended.

I have a very rough draft at:
https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags

I'm going to be traveling next week, so likely won't make the meeting, but I would like to discuss this in the following weeks meeting again and try and get an idea of what we would like to implement here.

As for the suggestion about programs that run as root, I think that is ambiguous. For example, 'ls' runs as root when the admin uses it. What we are after are daemons and setuid programs which may run as root. Yes, we want anything that parses untrusted content and I think we should give some examples: file, evince, elinks, dig, tcpdump, gimp, ... Untrusted content can be from the network or local that may have been tampered with.

The list of what should be PIE is also the list of apps that should have full RELRO support. After you have the relocations mapped, you want that table to be locked down. PIE without RELRO is a weaker application.

I would still suggest the same list for i686 because we still want the Full RELRO support for the same list.

From 2011-07-25 FESCo meeting:
* ACTION: ajax will create standard macros for enabling full RELRO/PIE
* AGREED: draft proposal at

https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags
is approved
* ACTION: nirik will take draft proposal to FPC
* AGREED: no mass rebuild at this time for this feature

Will leave open to track action items.

I have also made available a utility that can be used to assess if a package is following the intended policies. (Except for processing untrusted input...not sure there is a heuristic for that.) It is here:

http://people.redhat.com/sgrubb/files/rpm-chksec

used as this: ./rpm-chksec coreutils

Green is good, orange could be better but is acceptable, red needs fixing. You probably want to install libcapng-utils to be able to check file system based capabilities. It also has a summary mode that can be used to scan a whole distribution for compliance with policy:

./rpm-chksec --all

This will let the QE team check the whole distribution when they do their testing.

Guideline was accepted.

Login to comment on this ticket.

Metadata
None
None
None
None
None
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.