On Tue, 13.12.16 10:00, Matthew Miller (mattdm@xxxxxxxxxxxxxxxxx) wrote: > On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote: > > Well, the security policies need to be adapted to the service in > > question, hence a blanket switch to enable all of them for every > > service is problematic. Let's say you block gettimeofday() > > system-wide, but then run an NTP service: you just broke it... > > > > I fear it's too late to turn on all sandboxing options by default for > > regular services. If we would have had them back when we started we > > of course would have made them opt-out rather than opt-in, but that's > > too late now... > > I'm not so sure it's too late, if we would publicize the change well > enough in advance and have some proven packagers dedicated to finding > any exceptions. It's a matter of how much priority we put on > preventative security measures. Well, some of them are pretty drastic. For example, I think it would make a ton of sense to run all daemons where that's possible with ProtectSystem=strict. This would make the entire directory tree read-only for them (with the exception of API VFS, i.e. /proc, /sys, /dev), and then requires ReadWritePaths= to be used to whitelist the select few paths the service shall be able to write to. If we'd globally say that all services now run with ProtectSystem=strict by default, then we'd break pretty much all services that want to write something anywhere, until they get updated with the right ReadWritePaths= statements... And I have the suspicion that this kind of churn would upset quite a few people... I mean, I am all for breaking eggs to make an omelette, but not maybe not break all eggs in the egg carton at once ;-) (Also, note that things like ProtectSystem=, PrivateTmp=, PrivateDevices= aren't suitable for "meta" daemons such as crond or atd, as these daemon are supposed to run arbitrary user code, and its hence difficult to know where it makes sense to isolate them and where not, in particular as file system namespacing related options generally disconnect the service mount namespace from the host, and that means /bin/mount invocations done by such cron/at scripts would never have an effect on the host, but stay limited to the cron/at services. For such "meta" daemons it hence makes little sense to enable any sandboxing by default, so we'd have to update them too to then undo the default again locally.) Lennart -- Lennart Poettering, Red Hat _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
