lkml.org 
[lkml]   [2011]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] User namespace: don't allow sysctl in non-init user ns
Quoting Miquel van Smoorenburg (mikevs@xs4all.net):
> On Thu, 2011-09-15 at 14:48 -0500, Serge E. Hallyn wrote:
> > sysctl.c has its own custom uid check, which is not user namespace
> > aware. As discovered by Richard, that allows root in a container
> > privileged access to set all sysctls.
> >
> > To fix that, just refuse access if current is not in init_user_ns. We
> > may at some point want to relax that check so that some sysctls are
> > allowed - for instance dmesg_restrict when syslog is containerized.
> >
> > Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
> > Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> > Cc: Vasiliy Kulikov <segoon@openwall.com>
> > Cc: richard@nod.at
> > ---
> > kernel/sysctl.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index 11d65b5..f2b42e2 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -1697,6 +1697,8 @@ void register_sysctl_root(struct ctl_table_root *root)
> >
> > static int test_perm(int mode, int op)
> > {
> > + if (current_user_ns() != &init_user_ns)
> > + return -EACCES;
> > if (!current_euid())
> > mode >>= 6;
> > else if (in_egroup_p(0))
>
> I haven't tested it, but it looks like this denies access to /proc/sys
> completely, right ?

True. Good point.

> Wouldn't it be better to make access read-only ?

It'd be better, yes. For the moment we're trying to focus on making sure
there are no leaks out of the user namespace, so that then we can start
relaxing. But I think you're right, this is easy enough to do right
from the start.

> For example glibc reads from several /proc/sys/... files for sysconf()
> and pathconf(). That would fail with this patch I think ?
>
> Something like
>
> --- a/kernel/sysctl.c.orig 2011-06-24 00:24:26.000000000 +0200
> +++ b/kernel/sysctl.c 2011-09-21 11:40:42.961291629 +0200
> @@ -1892,10 +1892,15 @@
>
> static int test_perm(int mode, int op)
> {
> - if (!current_euid())
> - mode >>= 6;
> - else if (in_egroup_p(0))
> - mode >>= 3;
> + if (current_user_ns() != &init_user_ns) {
> + if (op & MAY_WRITE)
> + return -EACCES;
> + } else {
> + if (!current_euid())
> + mode >>= 6;
> + else if (in_egroup_p(0))
> + mode >>= 3;
> + }
> if ((op & ~mode & (MAY_READ|MAY_WRITE|MAY_EXEC)) == 0)
> return 0;
> return -EACCES;

How about the following, slightly changed? It tries to more precisely
follow the rule that access from another (non-ancestor) user-ns is
checked as access from the overflow userid (-1).

if (current_user_ns() == &init_user_ns) {
if (!current_euid())
mode >>= 6;
else if (in_egroup_p(0))
mode >>= 3;
}
if ((op & ~mode & (MAY_READ|MAY_WRITE|MAY_EXEC)) == 0)
return 0;
return -EACCES;

Does that make sense? Yes it does mean that any world-writeable
files are writeable from a container, but those are the rules
we'd earlier defined. (File creation (directory write) has to be
a special exception only because we don't have a valid owner to
assign to the new file).

Thanks for pointing this out!

-serge


\
 
 \ /
  Last update: 2011-09-21 15:17    [W:0.036 / U:6.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site