linux-kernel - Re: [Libcg-devel] [RFC] How to handle the rules engine for cgroups

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Jul 2008 21:19:43 +0530
From:	Dhaval Giani <dhaval@...ux.vnet.ibm.com>
To:	Paul Menage <menage@...gle.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>,
	Peter Zijlstra <pzijlstr@...hat.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Libcg Devel Mailing List <libcg-devel@...ts.sourceforge.net>,
	Morton Andrew Morton <akpm@...ux-foundation.org>,
	kamezawa.hiroyu@...fujitsu.com
Subject: Re: [Libcg-devel] [RFC] How to handle the rules engine for cgroups

On Thu, Jul 10, 2008 at 02:07:11AM -0700, Paul Menage wrote:
> Hi Vivek,
> 
> On Tue, Jul 1, 2008 at 12:11 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
> >
> > - netlink is not a reliable protocol.
> >        - Messages can be dropped and one can loose message. That means a
> >          newly forked process might never go into right group as meant.
> 
> One way that you could avoid the unreliability would be to not use
> netlink, but instead use cgroups itself.
> 
> What we're looking for is a way to easily distinguish between
> processes that are in the right cgroups, and processes that might be
> in the wrong cgroups. Additionally, we want the children of such
> processes to inherit the same status until we've dealt with them, and
> not be able to change their status themselves.
> 
> That sounds a bit like a cgroup. How about the following?
> 
> - create a cgroup subsystem called "setuid".
> 
> - have a uid_changed() hook called by sys_setuid() and friends; this
> hook would simply attach current to the root cgroup in the "setuid"
> hierarchy if it wasn't already in that cgroup (which can be determined
> with a couple of dereferences from current and no locking, so not
> slowing down the normal case).
> 
> - userspace uses this by:
> 
> mount the setuid hierarchy, e.g. at /mnt/setuid
> create a child cgroup /mnt/setuid/processed
> while true:
>   wait for /mnt/setuid/tasks to be non-empty
>   read a pid from /mnt/setuid/tasks
>   move that pid to the appropriate cgroups in memory/cpu/etc
> hierarchies if necessary
>   move that pid to /mnt/setuid/processed/tasks
> 
> i.e. any pid in the root cgroup of the setuid hierarchy is one that
> needs attention and may need to be moved to different cgroups
> 

Where I see complications is handling forks happening in that time. It
will take us a long time to ensure that a fork bomb goes into the
correct cgroup as an example.

Also another issue, where does the pid reside in the memory/cpu hierarchy.
If it is not in the correct cgroup at the time of exec, or soon after
exec, the wrong cgroup is getting charged.

I liked the other idea you posted about in the other mail, having
wrappers around. I believe that can be done at distro level, which
should not really be too tough.

Or maybe we can use something like selinux (ok, this really is a shot in
the dark, i should read up before opening my mouth here.)

Thanks,
-- 
regards,
Dhaval
--
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/