[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110923014031.GA27781@hallyn.com>
Date: Fri, 23 Sep 2011 01:40:31 +0000
From: "Serge E. Hallyn" <serge@...lyn.com>
To: "Serge E. Hallyn" <serge.hallyn@...onical.com>
Cc: Miquel van Smoorenburg <mikevs@...all.net>,
linux-kernel@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>, richard@....at,
akpm@...ux-foundation.org
Subject: [PATCH] User namespace: don't allow sysctl in non-init user ns (v2)
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, don't compare uid or groups if current is not in the
initial user namespace. We may at some point want to relax that check
so that some sysctls are allowed - for instance dmesg_restrict when
syslog is containerized.
Changelog:
Sep 22: As Miquel van Smoorenburg pointed out, rather than always
refusing access if not in initial user_ns, we should allow
world access rights to sysctl files. We just want to prevent
a task in a non-init user namespace from getting the root user
or group access rights.
Signed-off-by: Serge Hallyn <serge.hallyn@...onical.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Vasiliy Kulikov <segoon@...nwall.com>
Cc: richard@....at
Cc: Miquel van Smoorenburg <mikevs@...all.net>
---
kernel/sysctl.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 11d65b5..95988dc 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1697,10 +1697,12 @@ void register_sysctl_root(struct ctl_table_root *root)
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 (!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;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists