lkml.org 
[lkml]   [2010]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] p9auth: add p9auth driver
Quoting Eric Paris (eparis@redhat.com):
> 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


\
 
 \ /
  Last update: 2010-04-21 16:33    [W:0.053 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site