[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Andy Lutomirski]

On Apr 20, 2015 9:07 AM, "Lennart Poettering" <lennart at poettering.net>
wrote:
>
> On Mon, 20.04.15 08:51, Andy Lutomirski (luto at 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.

Sandstorm.io

I bet Chromium will follow suit, and don't forget Docker and similar tools.

>
> 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?
>

Nope, userns works just fine.

> 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:

There's a world outside systemd and, in that world, programs would like to
be able to sandbox themselves.  Userns is wonderful for that purpose.

>
>     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!

Except that if it's too coarse-gained, it fails to actually separate
privileges.

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150420/b9782ba8/attachment.html>