Prev: p9auth: add CAP_GRANT_ID to authorize use of /dev/caphash
Next: firmware loader: embed device into firmware_priv structure
From: Serge E. Hallyn on 21 Apr 2010 09:50
Quoting Ashwin Ganti (ashwin.ganti(a)gmail.com):
> On Tue, Apr 20, 2010 at 8:45 PM, Serge E. Hallyn <serue(a)us.ibm.com> wrote:
> > Quoting Greg KH (greg(a)kroah.com):
> >> Hm, who is going to maintain this, you, or Ashwin?
> >
> > I haven't asked Ashwin, and will be happy either way. �Ashwin, did
> > you want to maintain it?
>
> Well, since you have been driving a lot of implementation changes
> recently, I feel it makes sense for you to be a maintainer. Honestly I
> don't think I will be able to find time maintaining this in the future
> although I can do the code reviews for you. I will be more than happy
> if this feature continues to get traction.
>
> - Ashwin

Ok. I'll put myself in MAINTAINERS. If we stick with the p9auth
driver or filesystem approach, I'd like to keep you in MODULE_AUTHOR()
if that's ok, bc it really is yours, and wouldn't exist without you.

thanks,
-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Eric Paris on 21 Apr 2010 10:00
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
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 21 Apr 2010 10:20
> sorry I thought I had cc:d you, bc I was pretty sure you'd have some
> neat ideas. Like this one.
>
> One could try to argue that this makes every linux process susceptible
> to a trojan making it grant its userid to other tasks, but of course
> that's silly since the trojan could just fork. Well, what this would
> buy the attacker is the ability to sit inconspicuously under his old
> userid, holding on to the fd until the admin goes out to coffee before
> switching userids.

Possibly, could you put a timestamp in the passed object ? (Given the
expiry of such a uid offer is kind of policy)

> The other thing is that offhand I think the server can't easily tell
> from the socket which user namespace the client is in, as ucred only
> has .uid. Though (1) we might need to create a 'struct puser' analogous
> to 'struct pid' for signals anyway, (2) userspace can segragate with
> fs or net_ns (if abstract sock), and (3) client in a container
> presumably won't be able to authenticate itself to server on the
> host anyway.

That I think needs fixing anyway and now is a good time as any to do it.
If you are going to be able to pass userids then you need to be sure you
don't get passed a handle with a uid change on it that you didn't want so
adding another object type and option of some kind to accept them has to
occur anyway.

That also btw needs fixing for other reasons - more than one daemon has
been written that generically uses recvmsg and so can be attacked with FD
leaks >-)

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Serge E. Hallyn on 21 Apr 2010 10:40
Quoting Eric Paris (eparis(a)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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ashwin Ganti on 21 Apr 2010 10:50
On Wed, Apr 21, 2010 at 6:47 AM, Serge E. Hallyn <serue(a)us.ibm.com> wrote:
> Quoting Ashwin Ganti (ashwin.ganti(a)gmail.com):
>> On Tue, Apr 20, 2010 at 8:45 PM, Serge E. Hallyn <serue(a)us.ibm.com> wrote:
>> > Quoting Greg KH (greg(a)kroah.com):
>> >> Hm, who is going to maintain this, you, or Ashwin?
>> >
>> > I haven't asked Ashwin, and will be happy either way. �Ashwin, did
>> > you want to maintain it?
>>
>> Well, since you have been driving a lot of implementation changes
>> recently, I feel it makes sense for you to be a maintainer. Honestly I
>> don't think I will be able to find time maintaining this in the future
>> although I can do the code reviews for you. I will be more than happy
>> if this feature continues to get traction.
>>
>> - Ashwin
>
> Ok. �I'll put myself in MAINTAINERS. �If we stick with the p9auth
> driver or filesystem approach, I'd like to keep you in MODULE_AUTHOR()
> if that's ok, bc it really is yours, and wouldn't exist without you.

Yeah, sure.

- Ashwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: p9auth: add CAP_GRANT_ID to authorize use of /dev/caphash
Next: firmware loader: embed device into firmware_priv structure