On Mon, 20.04.15 08:51, Andy Lutomirski (l...@amacapital.net) wrote:
> > > > I will grant you that they aren't particularly expressive, and I will
> > > > grant you that one day there might be better concepts. But that's not
> > > > a strong reason not to support them really, that's just a reason to
> > > > later add support for something better.
> > >
> > > Technical reasons:
> > >
> > > 1. They can't be usefully delegated to a namespace.
> >
> > Not sure I can parse that. If you use the bus to communicate across
> > namespace boundaries then each side lacks caps for the other. Great,
> > that's how it should be. And same as for uid checks btw... if a uid
> > cannot be translated, then it will not be passed!
>
> No. You're right for nspawn-style namespaces, but not for namespaces more
> broadly. Namespaces are a great way to drop various privileges, but your
> use of caps prevents certain uses (e.g. confining your hypothetical
> time-setting daemon in a namespace).
I have seen no use of userns for sandboxing normal daemons so far. I
have seen tons of daemons using caps for such sandboxing.
maybe if userns in its current iteration doesn't mix as well as you'd
like it with caps this is indication that userns might need some more
polish, and not that caps are necessarily the bad guy here?
I mean, as the one who added most of the sandboxing features we expose
in systemd .service files currently (including things like
ReadOnlyDirectories=, PrviateTmp=, PrivateNetwork= which are all based
on kernel namespacing), I completely fail to see how we could even
expose user namespace like this in a good way that would hold water?
Capability-based sandboxing on the other hand is much easier to
handle, and in many cases a highly efficient way to sandbox stuff. Two
examples:
systemd-networkd drops privileges, becomes the "systemd-network"
user, only retains CAP_NET_ADMIN. That's actually already a really
good sandbox!
systemd-timesyncd drops privileges, becomes the "systemd-timesync"
user, only retains CAP_SYS_TIME. And that's actually a really good
sandbox too!
Both daemons are network facing, hence sandboxing things like this is
actually of quite some importance, and it *works*! Today! And it is
easy! easy enough for most administrators to grok it easily! And
because of that it is actually *good* security!
And please don't discount these two daemons as irrelevant
examples. They are highly relevant, since they run on a good chunk of
Linux systems, as one of the few daemons that run really everywhere.
Caps *do* have good uses, please don't claim otherwise. They are a
*lot* more relevant on today's system than userns at least!
(Note that I am not saying that userns are really a bad idea or so, I
just would like to ask you to keep things in perspective: caps are
*good* -- even though they could be much better. And they are a ton
more useful and used than userns right now)
> > OK, they are not very expressive, I granted you that already. But they
> > are still more expressive than "uid == 0".
> >
> > That they are not expressive is something I can agree with, as
> > mentioned above, but I don't consider this a real issue not to using
> > them. I mean, it would be great if we had something better in the
> > kernel, like capsicum or whatever, but we don't. And since caps are
> > pretty well supported otherwise on Linux, and they are better then
> > simple uid == 0 checks, I think they should be supported by kdbus too.
>
> This is a bad excuse. Given that you're designing something new, you have
> plenty of room to do better.
We are not really in the business in designing comprehensive new
access control systems that can be used for in-kernel and in-userspace
subsystems.
Sure, we also have bus policy, but that given it's non-interactive
logic it's not really suitable for the uses where we need uid or caps
checks, i.e. dynamic access control within called methods that need to
check different privileges dynamically.
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
