Do we have a packaging policy for setuid now (was: Re: Documentation for F15's "Remove SETUID" Change?)
Resurrecting this thread ... On Tuesday, March 1, 2022 6:43:57 PM EST Michel Alexandre Salim wrote: > The subject of setuid came up in a private conversation recently, and to my > surprise we don't seem to have it documented in the packaging guidelines: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > Per https://fedoraproject.org/wiki/Features/RemoveSETUID#Documentation > > "We should change documentation on packaging guidelines to talk about > using file capabilities." > > but the only mention of capabilities seem to be that, if you use it or > suid, PIE must be enabled: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie > > Should this be documented somewhere, or if it's there but it's lost in > the wiki->docs migration, does anyone know where the documentation is? Do we have this documented now? I can still only find the two links you've already identified above. Anyway, xscreensaver in Fedora suffers from the same problem described in this Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007724 I thought I'd either file a bug or post a merge request to make %_libexecdir/xscreensaver-auth setuid, but I wanted to check if there's a policy about this first. JWZ has of course given a lot of thought to security, but the code is here in case we'd like to audit it: https://github.com/Zygo/xscreensaver/blob/master/driver/xscreensaver-auth.c On Wed, Mar 02, 2022 at 07:11:42PM -0500, Steve Grubb wrote: > As someone involved in that change, the situation was much worse back in > 2011. Almost everything was running as root. The inspection tools back then > were non-existent, which is what I wrote pscap and netcap. > > Now, a lot of things use capabilities with a few still running as root when > they don't need to be. But I have not looked at all daemons. The lesser used > ones may need checking. But I think maybe some guidance could be good. > Something like: Can you comment on whether the code above should or could use capabilities? It seems to need to do a broad range of things as root, not just editing /proc/self/oom_score_adj. > In general, if the package has --with-libcap or --with-libcapng, turn that > on. If a daemon can run as non-root with capabilities fix the config file to > do > that. If you have to give CAP_DAC_OVERRIDE to a daemon/application, you > probably have file ownership problems. Depending on the nature of the > problem, > one solution for this is to use group permissions to allow access. > > One option for not running as root can be the systemd capabilities options if > the app does not natively support capabilities. It should be noted that > systemd does this by using ambient capabilities. Ambient capabilities have > the property that any children also get the capabilities. And so does their > children and on and on.This means that if the daemon is exploitable and the > attacker launches a shell, the shell will also get the capabilities of the > parent. This makes them a target for attack. > > Any app with ambient capabilities should specifically drop them first thing > after startup. Dropping ambient capabilities does not drop the normal > capabilities. However, apps that use the systemd capabilities do so because > they are typically capability unaware. That means they are not likely to be > able to drop ambient capabilities. One solution is to add LD_PRELOAD=/usr/ > lib64/libdrop_ambient.so.0. It drops ambient capabilities in the library > constructor so the app is defanged. > > I think the PIE thing should not be related to setuid or capabilities. The > guidance now should be everything should be PIE and full RELRO. That should > be reflected in the rpm-macros package. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Documentation for F15's "Remove SETUID" Change?
On Wed, Mar 2, 2022 at 7:15 PM Steve Grubb wrote: > As someone involved in that change, the situation was much worse back in > 2011. Almost everything was running as root. The inspection tools back then > were non-existent, which is what I wrote pscap and netcap. > > Now, a lot of things use capabilities with a few still running as root when > they don't need to be. [...] Not... really. grep is telling me there are 22 spec files that say %cap and 63 that match /%attr.4/. - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Documentation for F15's "Remove SETUID" Change?
Hi Steve, On Wed, Mar 02, 2022 at 07:11:42PM -0500, Steve Grubb wrote: > Hello, > > On Tuesday, March 1, 2022 6:43:57 PM EST Michel Alexandre Salim wrote: > > The subject of setuid came up in a private conversation recently, and to my > > surprise we don't seem to have it documented in the packaging guidelines: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > > > Per https://fedoraproject.org/wiki/Features/RemoveSETUID#Documentation > > > > "We should change documentation on packaging guidelines to talk about > > using file capabilities." > > > > but the only mention of capabilities seem to be that, if you use it or > > suid, PIE must be enabled: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie > > > > Should this be documented somewhere, or if it's there but it's lost in > > the wiki->docs migration, does anyone know where the documentation is? > > As someone involved in that change, the situation was much worse back in > 2011. Almost everything was running as root. The inspection tools back then > were non-existent, which is what I wrote pscap and netcap. > > Now, a lot of things use capabilities with a few still running as root when > they don't need to be. But I have not looked at all daemons. The lesser used > ones may need checking. But I think maybe some guidance could be good. > Something like: > That's really comprehensive, thanks. Can we document this? I'm a bit worried about the situation where a packager and a reviewer don't have the institutional memory of "we recommend capabilities over setuid/setgid" and new setuid packages creeping in again. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Documentation for F15's "Remove SETUID" Change?
Hello, On Tuesday, March 1, 2022 6:43:57 PM EST Michel Alexandre Salim wrote: > The subject of setuid came up in a private conversation recently, and to my > surprise we don't seem to have it documented in the packaging guidelines: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > Per https://fedoraproject.org/wiki/Features/RemoveSETUID#Documentation > > "We should change documentation on packaging guidelines to talk about > using file capabilities." > > but the only mention of capabilities seem to be that, if you use it or > suid, PIE must be enabled: > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie > > Should this be documented somewhere, or if it's there but it's lost in > the wiki->docs migration, does anyone know where the documentation is? As someone involved in that change, the situation was much worse back in 2011. Almost everything was running as root. The inspection tools back then were non-existent, which is what I wrote pscap and netcap. Now, a lot of things use capabilities with a few still running as root when they don't need to be. But I have not looked at all daemons. The lesser used ones may need checking. But I think maybe some guidance could be good. Something like: In general, if the package has --with-libcap or --with-libcapng, turn that on. If a daemon can run as non-root with capabilities fix the config file to do that. If you have to give CAP_DAC_OVERRIDE to a daemon/application, you probably have file ownership problems. Depending on the nature of the problem, one solution for this is to use group permissions to allow access. One option for not running as root can be the systemd capabilities options if the app does not natively support capabilities. It should be noted that systemd does this by using ambient capabilities. Ambient capabilities have the property that any children also get the capabilities. And so does their children and on and on.This means that if the daemon is exploitable and the attacker launches a shell, the shell will also get the capabilities of the parent. This makes them a target for attack. Any app with ambient capabilities should specifically drop them first thing after startup. Dropping ambient capabilities does not drop the normal capabilities. However, apps that use the systemd capabilities do so because they are typically capability unaware. That means they are not likely to be able to drop ambient capabilities. One solution is to add LD_PRELOAD=/usr/ lib64/libdrop_ambient.so.0. It drops ambient capabilities in the library constructor so the app is defanged. I think the PIE thing should not be related to setuid or capabilities. The guidance now should be everything should be PIE and full RELRO. That should be reflected in the rpm-macros package. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
