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.