[systemd-devel] SD_BUS_VTABLE_CAPABILITY

[Lennart Poettering]

On Thu, 16.04.15 12:45, Cameron Norman (camerontnorman at gmail.com) wrote:

> On Thu, Apr 16, 2015 at 9:43 AM, Tom Gundersen <teg at jklm.no> wrote:
> > On Thu, Apr 16, 2015 at 4:52 PM, Andy Lutomirski <luto at amacapital.net> wrote:
> >> The ratio of complexity of capability code the kdbus folks have
> >> already written (hundreds of lines across multiple files) to its
> >> utility (very near zero AFAICT) is, in my book, not a good sign at
> >> all.
> >
> > We have several uses of this, see my mail to Jiri regarding
> > CAP_SYS_BOOT for instance:
> >   https://lkml.org/lkml/2015/4/16/219
> >
> 
> This could easily be done with polkit and a special `boot` group. Why
> does it need to use CAP_SYS_BOOT? I mean why would you even *want*
> CAP_SYS_BOOT to be used for this? Using CAP_SYS_BOOT means that
> anything you want to let cleanly shutdown the system you would also
> allow to do a hard shutdown and thus cause data loss in many cases.
> 
> In summary: not **necessary** or **ideal** to use a capability in
> this case.

Well, I believe it is certainly a good idea to protect the same
operations with the same privileges, instead of inventing new
privileges for everything, or littering the system with numerous unix
groups. I also believe that if you possess the privilege for the
dangerous operation you should also have the privilege for the safer
alternative.

Anyway, nothing is "necessary", nothing is "ideal". I mean, have a
multi-user OS is not "necessary", you can also decide to just trust
everybody. You can also decide that today's Linux is "good
enough". And you are probably right.

However, it's not about being "necessary" or "ideal". It's about being
*desirable*. And yes, I believe that strongly: it simplifies the
permission model quite substantially, as kernel and userspace agree on
the same privileges for the same operations. And it allows good
lockdown as shown in examples in this thread.

> If you could be so kind, could you summarize the other uses you have?
> And if you can, explain why using regular user/group credentials does
> not achieve the goal.

Groups *suck* as authentication scheme. If you add one group for each
privilege you want, then you'll have a huge number of groups, and
that's hardly desirable. It's pretty close to being unmanagable with
user/group editors. Also, you can never take group membership away,
since users who once where members of group can create sgid binaries
which allows them to always return into that group forever.

Do not misuse UNIX groups as way to express large amounts of
privileges. THis cannot fly.

Lennart

-- 
Lennart Poettering, Red Hat