Re: [systemd-devel] [PATCH] units: add SecureBits
On Sat, 14.02.15 12:32, Topi Miettinen (toiwo...@gmail.com) wrote: Sorry for the late response, still going through piles of mail. No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. So, hmm, after reading the man page again: what's the rationale for precisely these bits? I mean no-setuid-fixup seems to be something that applies to setuid(), setresuid() calls and suchlike, which seems pretty uninteresting. Much more interesting is SECBIT_NOROOT, which disables suid binary handling... Yes, noroot noroot-locked was actually my intention, sorry. I'll update the patch. Maybe all of noroot noroot-locked no-setuid-fixup no-setuid-fixup-locked would be OK, but that probably needs another look at the programs if they switch UIDs. I'd be careful with more than noroot, since the other flags alter bbehaviour across setuid() and similar calls, and much of our code makes assumptions that will likely not hold if you set those bits... Going back to no-setuid-fixup no-setuid-fixup-locked: First, I looked at the kernel code if it matches the description on the manual page capabilities(7) to prevent more embarrassment. In this case it does, NO_SETUID_FIXUP prevents capability changes when the task calls set[res]*uid(). Any kind of changes? Both dropping and acquiring them? I mean, I think we should actually allow dropping them unless we explicitly say no during one transition. I have the suspicion that the SECBIT_NOROOT thing is the only really interesting one... There's of course the question whether no-setuid-fixup no-setuid-fixup-locked is useful. For daemons runnig as root, it would not help anything (or could even make things worse e.g. in the library case). But when the daemon runs as a different user, the flags could make the life of attacker a tiny bit more difficult. This leaves only: systemd-journal-gatewayd.service systemd-journal-remote.service systemd-journal-upload.service I can make a patch for those if you agree, or the original patch can be applied selectively. Maybe more daemons should run as unprivileged user. I think all long-running ones that reasonably can already do. I mean, things like logind simple need too many caps, it's really not worth trying to make them run under a different uid, because they have so much privs otherwise... Which daemons do you precisely have in mind? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: add SecureBits
On 04/24/15 14:52, Lennart Poettering wrote: On Sat, 14.02.15 12:32, Topi Miettinen (toiwo...@gmail.com) wrote: Sorry for the late response, still going through piles of mail. No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. So, hmm, after reading the man page again: what's the rationale for precisely these bits? I mean no-setuid-fixup seems to be something that applies to setuid(), setresuid() calls and suchlike, which seems pretty uninteresting. Much more interesting is SECBIT_NOROOT, which disables suid binary handling... Yes, noroot noroot-locked was actually my intention, sorry. I'll update the patch. Maybe all of noroot noroot-locked no-setuid-fixup no-setuid-fixup-locked would be OK, but that probably needs another look at the programs if they switch UIDs. I'd be careful with more than noroot, since the other flags alter bbehaviour across setuid() and similar calls, and much of our code makes assumptions that will likely not hold if you set those bits... Going back to no-setuid-fixup no-setuid-fixup-locked: First, I looked at the kernel code if it matches the description on the manual page capabilities(7) to prevent more embarrassment. In this case it does, NO_SETUID_FIXUP prevents capability changes when the task calls set[res]*uid(). Any kind of changes? Both dropping and acquiring them? I mean, I think we should actually allow dropping them unless we explicitly say no during one transition. Both ways IIRC. I have the suspicion that the SECBIT_NOROOT thing is the only really interesting one... I think they are all pretty much useless. SECURE_NOROOT could be improved by splitting it to two bits, one controlling setuid execution and the other to control whether capabilities are dropped at exec(). At least the manual page should be in synch with reality. Perhaps MAC systems would be better to enforce capability limits throughout the whole system. Unfortunately my favourite, TOMOYO, does not manage capabilities. There's of course the question whether no-setuid-fixup no-setuid-fixup-locked is useful. For daemons runnig as root, it would not help anything (or could even make things worse e.g. in the library case). But when the daemon runs as a different user, the flags could make the life of attacker a tiny bit more difficult. This leaves only: systemd-journal-gatewayd.service systemd-journal-remote.service systemd-journal-upload.service I can make a patch for those if you agree, or the original patch can be applied selectively. Maybe more daemons should run as unprivileged user. I think all long-running ones that reasonably can already do. I mean, things like logind simple need too many caps, it's really not worth trying to make them run under a different uid, because they have so much privs otherwise... Which daemons do you precisely have in mind? Nothing in particular. Privilege separation could help even in cases where some caps need to be retained. -Topi Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: add SecureBits
On Fri, 24.04.15 16:42, Topi Miettinen (toiwo...@gmail.com) wrote: I think all long-running ones that reasonably can already do. I mean, things like logind simple need too many caps, it's really not worth trying to make them run under a different uid, because they have so much privs otherwise... Which daemons do you precisely have in mind? Nothing in particular. Privilege separation could help even in cases where some caps need to be retained. Sure! Note that networkd and timesyncd both setuid() to an unprivileged user, but do keep CAP_NET_ADMIN/CAP_SYS_TIME. In those case that's relatively easy to do, because they only require those two caps, and nothing else. But for stuff like logind its quite different, it needs a lot of caps... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: add SecureBits
On 02/11/15 16:32, Lennart Poettering wrote: On Wed, 11.02.15 16:24, Topi Miettinen (toiwo...@gmail.com) wrote: On 02/10/15 21:00, Lennart Poettering wrote: On Sat, 07.02.15 10:40, Topi Miettinen (toiwo...@gmail.com) wrote: No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. So, hmm, after reading the man page again: what's the rationale for precisely these bits? I mean no-setuid-fixup seems to be something that applies to setuid(), setresuid() calls and suchlike, which seems pretty uninteresting. Much more interesting is SECBIT_NOROOT, which disables suid binary handling... Yes, noroot noroot-locked was actually my intention, sorry. I'll update the patch. Maybe all of noroot noroot-locked no-setuid-fixup no-setuid-fixup-locked would be OK, but that probably needs another look at the programs if they switch UIDs. I'd be careful with more than noroot, since the other flags alter bbehaviour across setuid() and similar calls, and much of our code makes assumptions that will likely not hold if you set those bits... Going back to no-setuid-fixup no-setuid-fixup-locked: First, I looked at the kernel code if it matches the description on the manual page capabilities(7) to prevent more embarrassment. In this case it does, NO_SETUID_FIXUP prevents capability changes when the task calls set[res]*uid(). Then I looked at all use cases of set[res]*uid() in systemd. They are called directly by run and nspawn. Then they are used when connecting to journal and setting up PAM in exec_spawn() as well as in namespace_enter(). These in turn are used by sd-bus init which is used by unit setup, so pretty much everything is affected. The good thing is that none of the daemons except machined use these directly. drop_privileges() uses set[res]*uid() and it is called from resolved, coredump, networkd, timesyncd and bus-proxyd. So avoiding those, at least the following could be candidates: systemd-hostnamed.service systemd-importd.service systemd-journal-gatewayd.service systemd-journal-remote.service systemd-journal-upload.service systemd-journald.service systemd-localed.service systemd-logind.service systemd-timedated.service It could still be possible that an external library could detect that uid==0 and then switch uids to do things at lower privilege. This would work, but the capabilities would not be dropped. There's of course the question whether no-setuid-fixup no-setuid-fixup-locked is useful. For daemons runnig as root, it would not help anything (or could even make things worse e.g. in the library case). But when the daemon runs as a different user, the flags could make the life of attacker a tiny bit more difficult. This leaves only: systemd-journal-gatewayd.service systemd-journal-remote.service systemd-journal-upload.service I can make a patch for those if you agree, or the original patch can be applied selectively. Maybe more daemons should run as unprivileged user. -Topi Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: add SecureBits
On 02/10/15 21:00, Lennart Poettering wrote: On Sat, 07.02.15 10:40, Topi Miettinen (toiwo...@gmail.com) wrote: No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. So, hmm, after reading the man page again: what's the rationale for precisely these bits? I mean no-setuid-fixup seems to be something that applies to setuid(), setresuid() calls and suchlike, which seems pretty uninteresting. Much more interesting is SECBIT_NOROOT, which disables suid binary handling... Yes, noroot noroot-locked was actually my intention, sorry. I'll update the patch. Maybe all of noroot noroot-locked no-setuid-fixup no-setuid-fixup-locked would be OK, but that probably needs another look at the programs if they switch UIDs. -Topi Can you elaborate? Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: add SecureBits
On Wed, 11.02.15 16:24, Topi Miettinen (toiwo...@gmail.com) wrote: On 02/10/15 21:00, Lennart Poettering wrote: On Sat, 07.02.15 10:40, Topi Miettinen (toiwo...@gmail.com) wrote: No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. So, hmm, after reading the man page again: what's the rationale for precisely these bits? I mean no-setuid-fixup seems to be something that applies to setuid(), setresuid() calls and suchlike, which seems pretty uninteresting. Much more interesting is SECBIT_NOROOT, which disables suid binary handling... Yes, noroot noroot-locked was actually my intention, sorry. I'll update the patch. Maybe all of noroot noroot-locked no-setuid-fixup no-setuid-fixup-locked would be OK, but that probably needs another look at the programs if they switch UIDs. I'd be careful with more than noroot, since the other flags alter bbehaviour across setuid() and similar calls, and much of our code makes assumptions that will likely not hold if you set those bits... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: add SecureBits
On Sat, 07.02.15 10:40, Topi Miettinen (toiwo...@gmail.com) wrote: No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. So, hmm, after reading the man page again: what's the rationale for precisely these bits? I mean no-setuid-fixup seems to be something that applies to setuid(), setresuid() calls and suchlike, which seems pretty uninteresting. Much more interesting is SECBIT_NOROOT, which disables suid binary handling... Can you elaborate? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] units: add SecureBits
No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. --- units/systemd-hostnamed.service.in| 1 + units/systemd-importd.service.in | 1 + units/systemd-journal-gatewayd.service.in | 1 + units/systemd-journal-remote.service.in | 1 + units/systemd-journal-upload.service.in | 1 + units/systemd-journald.service.in | 1 + units/systemd-localed.service.in | 1 + units/systemd-logind.service.in | 1 + units/systemd-machined.service.in | 1 + units/systemd-networkd.service.in | 1 + units/systemd-resolved.service.in | 1 + units/systemd-timedated.service.in| 1 + units/systemd-timesyncd.service.in| 1 + 13 files changed, 13 insertions(+) diff --git a/units/systemd-hostnamed.service.in b/units/systemd-hostnamed.service.in index cc88ecd..ec13938 100644 --- a/units/systemd-hostnamed.service.in +++ b/units/systemd-hostnamed.service.in @@ -14,6 +14,7 @@ Documentation=http://www.freedesktop.org/wiki/Software/systemd/hostnamed ExecStart=@rootlibexecdir@/systemd-hostnamed BusName=org.freedesktop.hostname1 CapabilityBoundingSet=CAP_SYS_ADMIN +SecureBits=no-setuid-fixup no-setuid-fixup-locked WatchdogSec=1min PrivateTmp=yes PrivateDevices=yes diff --git a/units/systemd-importd.service.in b/units/systemd-importd.service.in index 26759ea..bb3fbea 100644 --- a/units/systemd-importd.service.in +++ b/units/systemd-importd.service.in @@ -14,6 +14,7 @@ ExecStart=@rootlibexecdir@/systemd-importd BusName=org.freedesktop.import1 CapabilityBoundingSet=CAP_CHOWN CAP_FOWNER CAP_FSETID CAP_MKNOD CAP_SETFCAP CAP_SYS_ADMIN CAP_SETPCAP NoNewPrivileges=yes +SecureBits=no-setuid-fixup no-setuid-fixup-locked WatchdogSec=1min PrivateTmp=yes ProtectSystem=full diff --git a/units/systemd-journal-gatewayd.service.in b/units/systemd-journal-gatewayd.service.in index 987220e..bfdb561 100644 --- a/units/systemd-journal-gatewayd.service.in +++ b/units/systemd-journal-gatewayd.service.in @@ -11,6 +11,7 @@ Requires=systemd-journal-gatewayd.socket [Service] ExecStart=@rootlibexecdir@/systemd-journal-gatewayd +SecureBits=no-setuid-fixup no-setuid-fixup-locked User=systemd-journal-gateway Group=systemd-journal-gateway SupplementaryGroups=systemd-journal diff --git a/units/systemd-journal-remote.service.in b/units/systemd-journal-remote.service.in index 4a898d6..4f25518 100644 --- a/units/systemd-journal-remote.service.in +++ b/units/systemd-journal-remote.service.in @@ -13,6 +13,7 @@ Requires=systemd-journal-remote.socket ExecStart=@rootlibexecdir@/systemd-journal-remote \ --listen-https=-3 \ --output=/var/log/journal/remote/ +SecureBits=no-setuid-fixup no-setuid-fixup-locked User=systemd-journal-remote Group=systemd-journal-remote PrivateTmp=yes diff --git a/units/systemd-journal-upload.service.in b/units/systemd-journal-upload.service.in index b2e3c76..ac776ac 100644 --- a/units/systemd-journal-upload.service.in +++ b/units/systemd-journal-upload.service.in @@ -12,6 +12,7 @@ After=network.target [Service] ExecStart=@rootlibexecdir@/systemd-journal-upload \ --save-state +SecureBits=no-setuid-fixup no-setuid-fixup-locked User=systemd-journal-upload PrivateTmp=yes PrivateDevices=yes diff --git a/units/systemd-journald.service.in b/units/systemd-journald.service.in index a3540c6..01bf2a7 100644 --- a/units/systemd-journald.service.in +++ b/units/systemd-journald.service.in @@ -22,6 +22,7 @@ RestartSec=0 NotifyAccess=all StandardOutput=null CapabilityBoundingSet=CAP_SYS_ADMIN CAP_DAC_OVERRIDE CAP_SYS_PTRACE CAP_SYSLOG CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_CHOWN CAP_DAC_READ_SEARCH CAP_FOWNER CAP_SETUID CAP_SETGID CAP_MAC_OVERRIDE +SecureBits=no-setuid-fixup no-setuid-fixup-locked WatchdogSec=1min FileDescriptorStoreMax=1024 diff --git a/units/systemd-localed.service.in b/units/systemd-localed.service.in index bfa0978..f0c06aa 100644 --- a/units/systemd-localed.service.in +++ b/units/systemd-localed.service.in @@ -14,6 +14,7 @@ Documentation=http://www.freedesktop.org/wiki/Software/systemd/localed ExecStart=@rootlibexecdir@/systemd-localed BusName=org.freedesktop.locale1 CapabilityBoundingSet= +SecureBits=no-setuid-fixup no-setuid-fixup-locked WatchdogSec=1min PrivateTmp=yes PrivateDevices=yes diff --git a/units/systemd-logind.service.in b/units/systemd-logind.service.in index f087e99..f6760c6 100644 --- a/units/systemd-logind.service.in +++ b/units/systemd-logind.service.in @@ -24,6 +24,7 @@ Restart=always RestartSec=0 BusName=org.freedesktop.login1 CapabilityBoundingSet=CAP_SYS_ADMIN CAP_MAC_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG +SecureBits=no-setuid-fixup no-setuid-fixup-locked WatchdogSec=1min # Increase the default a bit in order to allow many simultaneous diff --git a/units/systemd-machined.service.in
