Re: [PATCH 2/4] autofs4 - track uid and gid of last mount requester

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Serge E. Hallyn
Date: Friday, August 8, 2008 - 8:23 am

Quoting Ian Kent (raven@themaw.net):

Based on that I can't quite tell whether there is any security property
that could be violated by uid 500 'tricking' the autofs daemon into
doing something for uid 0.  It sounds like it could be annoying but
not a security violation?


Well user namespaces are still being implemented, in fact at some level
still being designed.  So it doesn't hurt to consider the right thing
to do right off the bat, but unlike the pid namespaces this really shouldn't
be hurting anyone right now.

User namespaces will be hierarchical - like pid namespaces, except
somewhat differently.  If user 500 in userns 0 creates a new user
namespace, then each userid in the new user namespace is also
'owned' by (500,0).  Our hope is that we can make the userns
core such that unprivileged users can safely unshare a new pid
namespace.  So for that reason, I suspect we'll want to handle
user namespace much like I just suggested handling pid namespaces.

1. For each 'system container', that is, a process set with its
own network stack, its own devices, etc, we'll want separate
autofs daemons.  That's simple enough - apart from determining
what qualifies as a 'system container'.  Here I think that will
depend on how autofs talks to the userspace daemon, and what
needs to be isolated in order to prevent a surreptitious admin
in one system container from having its autofs daemon talk to
another.

2. Within a system container, I think we'll want the autofs
daemon to store a pointer to its user namespace.  When an
autofs4_wait happens, the wq uses the full current->user
to look up the task's uid within the autofs daemon's own user
namespace, and it uses for macro expansions.

That prevents unprivileged user hallyn from creating a new
user namespace and trying to fool autofs into expanding
macros for uid 0.

Note that certainly for now and probably a long time coming,
you do need privilege to clone(CLONE_NEWUSER) so this isn't
urgent.

thanks,
-serge
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 2/4] autofs4 - track uid and gid of last mount ..., Serge E. Hallyn, (Fri Aug 8, 8:23 am)
Re: [PATCH 1/4] autofs4 - cleanup autofs mount type usage, Christoph Hellwig, (Sat Aug 9, 5:47 am)
Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls, Christoph Hellwig, (Sat Aug 9, 5:59 am)
Re: [PATCH 3/4] autofs4 - devicer node ioctl docoumentation., Christoph Hellwig, (Sat Aug 9, 6:00 am)
Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls, Christoph Hellwig, (Sat Aug 9, 10:18 am)
Re: [PATCH 2/4] autofs4 - track uid and gid of last mount ..., Serge E. Hallyn, (Mon Aug 25, 11:05 am)