On Do, 24.02.22 16:29, Marius Schwarz (fedoradev@xxxxxxxxxxxx) wrote: > Do those "insecure" units come from upstream projects, or is Fedora lagging > behind some patches? "insecure" is misleading. We call it "exposed", which is a different thing. > Is there a way to find out, if missing restrictions options are a problem > for the service and if not, any way to tell that analyse tool about it? There is no tool such as SELinux' "audit2allow" fo the sandboxing knobs of systemd services, if that's what you are asking for. Writing one is not that easy, since the various knobs we expose use quite different subsystems to do what they do, and typically the logging/reporting of access conflicts on each is quite different. So yeah, things suck a bit on that front. I'd assume that sandboxing options for services are enabled by upstreams, as they should know best what the services really need. Hence, I'd always work with upstreams on this, and not make this a Fedora-specific enhancement. Note that some services are better candidates for sandboxing than others. i.e. some low-level software needs a lot of integration with the OS, in particular a lot of the stuff shipped with systemd itself. If you see the OS as a tree, then it's likely more the "leaves" of the tree that can be sandboxed, rather than the "trunk". And then, services that are overly generic, i.e. app servers for other applications can typically be sandboxed only quite badly. One good example for that is crond: you never know what cron jobs intend to do, hence you cannot sandbox crond as a whole reasonably. Moreover, runtime matters: short-lived stuff is much less exposed than continously running stuff. In systemd itslef the various long-running components are thus all sandboxed, while the short-lived stuff (e.g. the tool that loads the brightness setting for your screen) we didn't bother too much with. So, to summarize: sandboxing is great, we should do more of, but it's not trivial to do so, probably needs involvement of upstreams, and one should never make blanket statements over the entire OS, since our services vary so wildly in what they need to do. Would love for a workgroup or so to go through all services we ship with fedora, identify the long-running ones where sandboxing could be done, and then work with upstreams do fix the unit files accordinlgy. But it requires some man power behind it (like for any other job in open source) Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
