linux-kernel - Re: [RFC PATCH 1/2] devices cgroup: allow can_attach() if ns

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 5 Nov 2013 07:06:59 +0900
From:	Tejun Heo <tj@...nel.org>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Serge Hallyn <serge.hallyn@...ntu.com>,
	Containers <containers@...ts.linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Victor Marmol <vmarmol@...gle.com>,
	Stéphane Graber <stgraber@...ntu.com>,
	Rohit Jnagal <jnagal@...gle.com>
Subject: Re: [RFC PATCH 1/2] devices cgroup: allow can_attach() if ns_capable

Hello,

On Mon, Nov 04, 2013 at 09:51:35PM +0000, Serge E. Hallyn wrote:
> Do you have a list of such issues which you see with delegation?  That is,
> cases where, if ownership of a subtree is granted to a non-root user,
> that user can affect tasks owned by other users who are in other
> cgroups?

A lot of security is about logistics and cgroup simply doesn't have
them - depth, number of cgroups quota, even config changes or
subdirectory operations which involve RCU operations can easily be
used for DoS attacks.  Just think about how much complexity and effort
need to be spent on making and maintaining anything properly
delegatable to !priv users.  cgroup has never spent such design or
implementation effort - e.g. take a look at how event_control thing is
implemented, it's extremely easy to trigger OOM if you give that out
to !priv users.

cgroup has *never* been safe to give out to !priv users and it is
highly unlikely to be in any foreseeable future.  It will be a big new
giant feature which I frankly don't think is worth the risk or effort.
Think of it as giving out sysctl or firewall rule control to !priv
users.  Giving out subset of those controls do make sense in terms of
function but we don't do that and don't have infrastructure to support
such usage.  cgroup at this stage isn't that different.  If you insist
on doing that, you can but it is severely compromising in terms of
security and it'll stay that way for the foreseeable future.

Thanks.

-- 
tejun
--
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/