Am 23.07.2013 19:35, schrieb Bill Nottingham: > 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 that was only an example the proposal was only for * ReadOnlyDirectories=/etc * ReadOnlyDirectories=/usr it is not 100%, nothing is that exept mount /usr read-only which needs a lot of work and has a high impact while the above costs nothing and can be easily overriden if needed hence i see no reason why a network aware service would write to /usr > 2) It's also mixing specific implementation details (CapabilityBoundingSet) > with more abstract concepts mapped to implementation details (NoNewPrivileges). > That can leave the behavior confusing. again - the proposal was * ReadOnlyDirectories=/etc * ReadOnlyDirectories=/usr this doe snot need the packager understand much and additional things needs to be considered per service > 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. "needs" is not really correct needs to be *fully* enabled a potential submount would not be read-only so what - without this the rest would not be too > 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 explaine that's why i find "ReadOnlyDirectories=/usr" so dmaned useful
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
