Re: [PATCH 3/3] p9auth: add p9auth driver

From: Serge E. Hallyn
Date: Wed Apr 21 2010 - 10:30:38 EST


Quoting Eric Paris (eparis@xxxxxxxxxx):
> On Wed, 2010-04-21 at 10:27 +0100, Alan Cox wrote:
> > > This is a change which must be discussed. The use of this
> > > privilege can be completely prevented by having init remove
> > > CAP_GRANT_ID from its capability bounding set before forking any
> > > processes.
> >
> > Which is a minor back compat issue - but you could start without it and
> > allow init to add it.
> >
> > It seems a very complex interface to do a simple thing. A long time ago
> > there was discussion around extending the AF_UNIX fd passing to permit
> > 'pass handle and auth' so you could send someone a handle with a "become
> > me" token attached.
>
> If you do go down this path there is a separate (and actually completely
> opposite) but related problem I might be able and willing to work with
> you on. When looking at how auditing works in this modern day and age
> of dbus+polkit to get background processes to do work on behalf of a

This actually brings up an issue I've been a bit worried about: is
credentials passing for dbus adequate? I thought that the last time
I looked through some code, there was no way in particular for upstart
to pass posix capabilities info along. What that means is that as root
I can do

capsh --drop=(list of all capabilities) --
reboot

and, although I don't have cap_sys_boot, I can reboot the system. So
the only way I can prevent a container from rebooting the host is to
start it in a fresh network namespace to segrate the abstract unix
domain sockets. But if I don't want a fresh network namespace, I'm out
of luck.

> user we were discussing an interface that would pass the information
> about the user to the background server process. The background server
> process could do some magic such that it still had all the permissions
> and rights of itself, but had the audit information of the original
> user. Thus even though it was a server process with uid=0 that did the
> work, the audit logs could know it was actually on behalf of uid=500.
>
> It was discussed passing that token of audit information over an AF_UNIX
> socket.
>
> -Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/