Am 2014-10-20 17:05, schrieb Lennart Poettering:
I am sorry, but this is nothing we want to support. Monopolizing the
OS in /usr is what makes ProtectSystem= work. If you split things up
into many dirs then you will simply not get the same level of
protection. We will not try to list every possible dirs that the OS
might be split up to in systemd.
Why wouldn't you get the same level of protection, even if it is split
up? I mean, we are talking about /bin, /sbin, /lib and possibly some
pseudo-multiarch-variants for /lib - it's not like there are any other
directories, the /usr-merge is about moving /bin, /sbin and /lib to
/usr/$dir. I don't see that split-/usr with these additional
directories
protected would be inherently more insecure.
Note that your patch is likely to break systems that have the dirs
you
list as symlinks (which all systems that have /usr merged have).
But on those systems, systemd is going to be compiled without
HAVE_SPLIT_USR, right?
Also note that it hardcodes x86_64 peculiarities in an
arch-independent way, which looks pretty wrong too.
That is definitely a good point. Also note that /lib32 is not included
in the patch...
We are fine with supporting HAVE_SPLIT_USR work to the level where
things generally work, but given that ProtectSystem= is only an extra
layer of protection where nothing breaks if it doesn't fully protect
systems that haven't done the usr-merge I think applying this patch
is not useful.
But computer security often works as defence in depth. Of course
ProtectSystem is an additional security measure, and protecting /usr
alone is obviously still better than protecting nothing at all, but if
it is not much work to provide a slightly higher level of protection -
why not?
That all said, to add something constructive to this: If I put my
administrator hat on, I think I can come up with something that might
make all parties happy:
To start with, ProtectSystem does not include /opt. Now I don't suggest
adding that to the list: distributions by default do not install
anything there, therefore a vanilla installation of a reasonable
distribution will not be affected by this. And there might be software
which requires system services to be able to write to /opt (for
example,
think of some proprietary software that creates logfiles underneath
/opt
that you want to rotate, but want the logrotate-job to use
ProtectSystem, since it's run as root), so it's probably a good default
not to include it.
However, as an administrator, if I know what software is installed
underneath /opt, and that there is no need for services to write to it,
I might actually want to include it. Of course, I could add drop-ins
for
all services that use ProtectSystem to also have
ReadOnlyDirectories=/InaccessibleDirectories=, but that would mean as
an
administrator I have to track these services - and if an update
suddenly
changes service files to use ProtectSystem= for increased protection,
I'd likely miss that and not be able to add these directives.
Additionally, not all custom installations follow the FHS and put
everything in /opt. I've seen computing clusters where software was
installed centrally and mounted per NFS to some other top-level
directory that is not /opt and /usr.
Therefore, may I suggest to make this configurable in
/etc/systemd/system.conf:
- have an option such as ProtectSystemDirectories= that is a list
like the other *Directories= options for units
- set the default to /usr, -/boot (like currently)
- distributions can customize that to fit their needs (depending on
/lib{32,64}, split- or no-split-/usr, etc.)
- administrators may themselves add /opt and other directories if
needed
- still hard-code /etc for ProtectSystem=full
If you're willing to accept a patch for this, I'd provide one.
Christian
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
