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 -- _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
