Reindl Harald (h.reindl@xxxxxxxxxxxxx) said: > a httpd running with SElinux disabled or in permissive mode with > the 4 lines below even after escalate to root privileges will > hardly have a chance to overwrite /usr/sbin/sshd as example > > CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID > NoNewPrivileges=yes > ReadOnlyDirectories=/etc > ReadOnlyDirectories=/usr So I do see some issues with something like this, and I'll admit, they may not be easily solved. 1) This is 4 separate independent configuration directives (and leaves out things like SecureBits), not to mention it iterates over a list of capabilities. Setting all of them requires the admin/packager to understand the intersection of all of them, which may not be simple to apply correctly. (And you want to be careful with security controls in the hands of those not used to applying them correctly.) 2) It's also mixing specific implementation details (CapabilityBoundingSet) with more abstract concepts mapped to implementation details (NoNewPrivileges). That can leave the behavior confusing. 3) ReadOnlyDirectories also needs to be applied across submounts, which introduces complication to the system units depending on the filesystem layout on the administrator-configured machine - having security mechanisms be affected by this is not ideal. On the one hand, it's best to be explicit about what it's trying to do to secure the service, hence the many options to be set. On the other hand, it makes it much easier for the packager and admin to apply these sorts of service configurations correctly by mapping all options you'd need into more logical options that are easily explained. (Think of it as the same thing as exposing cgroupfs, vs exposing slices.) Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
