Ticket #563 (closed task: fixed)

Opened 3 years ago

Last modified 2 years ago

suggested policy: all daemons must set RELRO and PIE flags

Reported by: adamwill Owned by:
Priority: major Keywords:
Cc: sgrubb@…, ricky Blocked By:
Blocking:

Description

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

Change History

comment:1 Changed 3 years ago by kevin

  • Keywords meeting added

adding meeting keyword.

comment:2 Changed 3 years ago by kevin

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.

comment:3 Changed 3 years ago by tuxbrewr

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

SMP

comment:4 Changed 3 years ago by mmaslano

+1

comment:5 in reply to: ↑ description Changed 3 years ago by mclasen

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

comment:6 Changed 3 years ago by kyle

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

comment:7 Changed 3 years ago by adamwill

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.

comment:8 Changed 3 years ago by robert

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

comment:9 Changed 3 years ago by kevin

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.

comment:10 Changed 3 years ago by kevin

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

comment:11 Changed 3 years ago by kevin

Will revisit next week.

comment:12 Changed 3 years ago by mmaslano

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.

comment:13 Changed 3 years ago by kevin

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

comment:14 Changed 3 years ago by sgrubb

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.

comment:15 Changed 3 years ago by kevin

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?

comment:16 Changed 3 years ago by ricky

  • Cc ricky added

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.

comment:17 Changed 3 years ago by jakub

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.

comment:18 Changed 3 years ago by ajax

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

comment:19 Changed 3 years ago by kevin

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.

comment:20 Changed 3 years ago by sgrubb

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.

comment:21 Changed 3 years ago by sharkcz

comment:22 Changed 3 years ago by notting

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.

comment:24 Changed 3 years ago by sgrubb

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.

comment:25 Changed 3 years ago by ajax

  • Keywords meeting removed

comment:26 Changed 2 years ago by notting

  • Status changed from new to closed
  • Resolution set to fixed

Guideline was accepted.

Note: See TracTickets for help on using tickets.