Bug 914705
| Summary: | localed: dropping caps is ineffective | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Miloslav Trmač <mitr> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jan Ščotka <jscotka> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | harald, jscotka, systemd-maint-list |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | systemd-206-4.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-13 13:17:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
They already run at minimal capabilities (try "pscap"!). (In reply to comment #2) > They already run at minimal capabilities (try "pscap"!). Thanks, I'm not sure how I missed that. Running the services as a non-root user would still be preferable (because root owns most of the system files, and no capabilities are necessary to chmod() and overwrite them). Anyway, reopening for a different reason: the localed capability restriction doesn't work. It seems that /usr/lib/systemd/system/dbus-org.freedesktop.locale1.service is trying to remove all capabilities: > CapabilityBoundingSet= but per systemd.exec(7) and load-fragment.c:config_parse_bounding_set(), this resets the bounding set to "no restrictions" instead of removing all entries. pscap confirms: 1 27007 root systemd-localed full (In reply to comment #3) > Running the services as a non-root user would still be preferable (because > root owns most of the system files, and no capabilities are necessary to > chmod() and overwrite them). Hmm, any recommendation how to keep the ability to read all of /proc for all processes on the system? The journal needs to be able to do that, and that's the main reason we run as root atm. (In reply to comment #4) > (In reply to comment #3) > > Running the services as a non-root user would still be preferable (because > > root owns most of the system files, and no capabilities are necessary to > > chmod() and overwrite them). > > Hmm, any recommendation how to keep the ability to read all of /proc for all > processes on the system? The journal needs to be able to do that, and that's > the main reason we run as root atm. I really haven't looked at the details of what journald needs; however if it really needs to use all of the capabilities that it currently keeps, based on a comparison with http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 it's a lost cause - with these capabilities journald will have enough privileges to gain full system control anyway. (Well, SELinux restrictions will still aply, but that's orthogonal to the UID question, and to some extent to capabilities as well.) (The journal request was in a different bug; this bug is about {hostnamed,localed,timedated}.) The mechanisms need to read and write files owned by root. It would be really nasty dropping UID for that, unless we want to get into awful stuff such as setfsuid(). In general I believe it's a better idea to have root daemons with as many caps dropped as possible, with sane code rather than non-root daemons whith certain caps addedd, with awful code that uses setfsuid() all the time. (In reply to comment #6) > The mechanisms need to read and write files owned by root. It would be > really nasty dropping UID for that, unless we want to get into awful stuff > such as setfsuid(). > > In general I believe it's a better idea to have root daemons with as many > caps dropped as possible, with sane code rather than non-root daemons whith > certain caps addedd, with awful code that uses setfsuid() all the time. Right, if the code has privileges, running as root makes it more obvious that the administrator needs to be careful. The change I was thinking about (at least in the case of localed, which seems to be completely unprivileged?) is to just run the daemon as an ordinary unprivileged user ("localed"), and make the files (group-?) owned by the same user "localed". However that won't work when they are placed in /etc, because localed won't be able to create a temporary file and rename() in that directory. Oh well, hindsight... So, I suppose, we are left with the $subject of this bug report - localed running with unrestricted capabilities. Fixed in git. systemd-206-4.el7 Hi, capabilities applied #getpcaps `pidof systemd-localed` Capabilities for `3533': =ep cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,35,36-ep This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |
systemd-{hostnamed,localed,timedated} are some of the few auto-activated D-Bus services running as root (i.e. possible privilege escallation paths) that are available in the minimal install. (systemd-logind is presumably mandatory.) Please consider splitting them into a subpackage that can be removed. (If that were impossible, modifying them to run as a non-root user would also be an improvement, but the ability to remove them would be preferred.) Version-Release number of selected component (if applicable): Tested on Fedora 18 minimal install.