Re: Documentation for F15's "Remove SETUID" Change?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux