Proposal: ReadOnlyDirectories /etc and /usr for network-services

[Reindl Harald]

Am 23.07.2013 19:35, schrieb Bill Nottingham:
> Reindl Harald (h.reindl at thelounge.net) 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130723/46f2c1c5/attachment.sig>