[systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories

[Lennart Poettering]

On Tue, 21.10.14 15:57, Christian Seiler (christian at iwakd.de) wrote:

> Am 2014-10-21 14:28, schrieb Lennart Poettering:
> >We explicitly make no
> >assumptions on /opt because nobody knows right now what it is supposed
> >to be...
> 
> Sure, I wasn't disputing that point.
> 
> >Same for /usr, /bin, /sbin, and the other stuff Martin#s
> >patch added: we cannot make assumptions about it, it might be (and is
> >in real life) set up in different ways, and we don't want to be in
> >that game.
> 
> That's why I didn't suggest that you (as upstream) should be in that
> game, but that distributions and administrators should be able to do so
> themselves.

Will distros always are in charge, as they can for example merge
Martin's patch downstream. (Though I'd be careful.)

> >>Therefore, may I suggest to make this configurable in
> >>/etc/systemd/system.conf: [...]
> >>If you're willing to accept a patch for this, I'd provide one.
> >
> >I really disagree that this would be a good idea. We should give clear
> >guidelines how things should be set up here to take full benefit of
> >the functionality. Because this is about an agreement between the OS
> >people and the upstream developers of packages to run on the OS. We
> >want to make sure they can make the assumptions everywhere, which are
> >not configurable and behave differently everywhere. For example, I
> >really want that let's say apache sets ProtectSystem= and can be sure
> >it will just not break things on our OSes. And because of that its
> >impact should be only on the safe subset, and it should be the same on
> >all installations, and not be subject to configuration.
> 
> Debian's systemd package currently includes a variant of Martin's patch
> that does include additional directories. So your point that
> ProtectSystem= does the same thing on every distro is already not
> true.

Which ones precisely?

> Of course, if you make it configurable, people can shoot themselves in
> the foot. But you already have a ton of global options in system.conf
> that can break a lot of software if people do stupid stuff with it:
> 
>  - set a global CapabilityBoundingSet= that's very restrictive
>       - either the system doesn't boot at all because some essential
>         stuff is completely missing
>       - or it boots but some services don't work because they rely
>         on certain things

Well, it's a different thing really, I think. Finding resources in the
file system and access to certain anyway priviliged facilities are not
the same thing.

>  - set SystemCallArchitectures=native when non-native software is
>    installed

Same here. In this case the software will totally fail to run, the
failure is early and immediate.

>  - set DefaultEnvironment=LD_TRACE_LOADED_OBJECTS=1 or the such

Well, environment variables is something completely out of our reach,
we are not the ones defining them.

>  - set DefaultTimeoutStartSec=1 to break any unit that takes longer than
>    1 second to start but doesn't set an own timeout because it assumes
>    the default timeout is sane
>  - DefaultLimitCPU=1
>  - ...

Well, I am not against making certain parameters configurable. I am
simply saying that I don't want to make configurable how the base OS
is laid out.

> Also, to go to your apache example: it's not clear that ProtectSystem=
> just making /usr readonly doesn't break things: I have seen
> DocumentRoots beneath /usr in the wild (/usr/local/www or the such),
> with people running dynamic webapps that had to write into that tree. If
> you then upgrade from a package version that did not include
> ProtectSystem= (perhaps because it only included a SysV init script) to
> a package version that does include ProtectSystem=, things will
> break.

Well, sure everything new we introduce can break things. No doubt. But
that's really why I wrote "sufficiently sure" instead of "absolutely"
in my earlier mail.

> I actually agree with your sentiment of having an agreement between
> upstream developers and the core OS - I just think I would like to
> interpret the matter a little differently:
> 
> To me, ProtectSystem= is supposed to be a protection of all the files
>     a) installed on a system (not created by the user)
> and
>     b) not subject to modification by typical services. (i.e. not a
>        cache / status file / ...)
> For distros with /usr-move, this falls back to /usr and /boot (and /etc
> if =full). For other distros, there may be a few additional directories.
> And on a custom installation, it may include additional directories,
> such as /opt.

Again, I disagree with this definition. Consider looking at this from
an upstream perspective: if you are writing a unit file and really
want to lock things down, then you want to enable everything where you
understand the effect and what it entails. You also want to arrange
your package in a way that fits this nicely. We achieve that now with
the option, because we can explain in one or two sentences what this
is about and what upstream has to do to make this work nicely. But
sticking one configuration layer on top of another (i.e. making
ProtectSystem= something only vaguely defined that is configured with
a second level of configuration) completely destroys this goal.

Note that ProtectSystem= is actually entirely redundant. You can
achieve the same with manual ReadOnlyDirectories= lines. The only
reason it exists is to provide a nice, default logic that works
everywhere the same in a useful way. 

Hence: an admin has full control anyway, individually for each
service. ProtectSystem= is really just a friendly way to make it easy
for upstreams to adopt this scheme.

> If I am an upstream developer and ship a unit file with
> ProtectSystem=full, my expectations are that normal operation on
> directories that are supposed to contain data that is not put there at
> installation (such as /var, /tmp, /home, /srv, /run, ...) remain
> accessible, but that systemd will provide an extra layer of security
> around the rest of the installed system. As an upstream developer, I
> don't know where the distro the user is using decided to install stuff,
> whether it's in /usr or directly in /bin or wherever. 

It's not easy. As an upstream developer the paths matter, since you
need to drop your stuff at the right places.

As an upstream developer you must be able to make educated choices
where to place your stuff and how ProtectSystem= will affect it.

Anyway, I am really sure that I don#t want to carry a configuration
option for this upstream.

Lennart

-- 
Lennart Poettering, Red Hat