| |||||||||||||
Systemd gets seccomp filter supportSystemd gets seccomp filter supportPosted Jul 17, 2012 17:37 UTC (Tue) by sztanpet (subscriber, #60731)In reply to: Systemd gets seccomp filter support by walters Parent article: Systemd gets seccomp filter support
You can also create a blacklist of syscalls, which might be less "bad".
Anyway, the feature is worth it if only for the NoNewPrivileges options, quoting the manual:
"Takes a boolean argument. If true ensures that the service process and all its children can never gain new privileges. This option is more powerful than the respective secure bits flags (see above), as it also prohibits UID changes of any kind. This is the simplest, most effective way to ensure that a process and its children can never elevate privileges again."
(Log in to post comments)
Systemd gets seccomp filter support Posted Jul 17, 2012 21:39 UTC (Tue) by scientes (guest, #83068) [Link]
And just to make it clear. In order to use seccomp 2 as non-root, you need to first call No New Privs, this is why the seccomp feature implies no new privs, but you can set no new privs off if you really know what you are doing. (are are launching from the main systemd process that is root, and not a user-session systemd)
Systemd gets seccomp filter support Posted Jul 20, 2012 0:36 UTC (Fri) by luto (subscriber, #39314) [Link]
You don't need to be root to use PR_SET_NO_NEW_PRIVS.
Note that setting this is likely to defeat any selinux protections on the service (if any) -- until selinux adds some magic restrict-only mode and makes it work with no_new_privs, privilege transitions on exec won't happen.
systemd could get fancy and do the selinux transition itself, I suppose.
Take a look at the shiny docs in Documentation/prctl/no_new_privs.txt
|
|||||||||||||