From: Tejun Heo <tj@kernel.org>
To: Serge Hallyn <serge.hallyn@ubuntu.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
lkml <linux-kernel@vger.kernel.org>,
Containers <containers@lists.linux-foundation.org>
Subject: Re: [RFC PATCH 1/2] devices cgroup: allow can_attach() if ns_capable
Date: Tue, 23 Jul 2013 15:12:45 -0400 [thread overview]
Message-ID: <20130723191245.GI21100@mtj.dyndns.org> (raw)
In-Reply-To: <20130723190426.GA9577@tp>
Hello,
On Tue, Jul 23, 2013 at 02:04:26PM -0500, Serge Hallyn wrote:
> If task A is uid 1000 on the host, and creates task B as uid X in a new
> user namespace, then task A, still being uid 1000 on the host, is
> privileged with respect to B and his namespace - i.e.
> ns_capable(B->userns, CAP_SYS_ADMIN) is true.
Well, that also is the exact type of priv delegation we're moving away
from, so....
> > Besides, I find the whole check rather bogus and would actually much
> > prefer just nuking the check and just follow the standard permission
> > checks.
>
> I'd be ok with that - but there's one case I'm not sure about: If PAM
> sets me up with /sys/fs/cgroup/devices/serge owned by me, then if I'm
> thinking right, removing can_attach would mean I could move init into
> /sys/fs/cgroup/devices/serge...
>
> Is there something else stopping that from happening?
If PAM is giving out perms on cgroup directory, the whole system is
prone to DoS in various ways anyway. It's already utterly broken, so
kinda moot point. If there are people actually doing that in the
wild, we can conditionalize it on cgroup_sane_behavior().
Thanks.
--
tejun
next prev parent reply other threads:[~2013-07-23 19:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 18:16 Serge Hallyn
2013-07-23 18:18 ` [RFC PATCH 2/2] capabilities: allow nice if we are privileged Serge Hallyn
2013-07-24 8:07 ` Eric W. Biederman
2013-07-23 18:30 ` [RFC PATCH 1/2] devices cgroup: allow can_attach() if ns_capable Tejun Heo
2013-07-23 18:38 ` Serge Hallyn
2013-07-23 18:50 ` Tejun Heo
2013-07-23 19:04 ` Serge Hallyn
2013-07-23 19:12 ` Tejun Heo [this message]
2013-07-23 19:28 ` Serge Hallyn
2013-07-23 19:39 ` Tejun Heo
2013-11-04 21:51 ` Serge E. Hallyn
2013-11-04 22:06 ` Tejun Heo
2013-10-23 0:41 ` Serge E. Hallyn
2013-10-24 10:57 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130723191245.GI21100@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serge.hallyn@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome