linux-kernel - Re: [Workman-devel] cgroup: status-quo and userland efforts

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:	Tue, 3 Mar 2015 22:20:52 +0000 (UTC)
From:	Luke Leighton <lkcl@...l.net>
To:	linux-kernel@...r.kernel.org
Subject: Re: [Workman-devel] cgroup: status-quo and userland efforts

Serge Hallyn <serge.hallyn@...> writes:

> 
> Quoting Daniel P. Berrange (berrange@...):

> > Are you also planning to actually write a new cgroup parent manager
> > daemon too ? Currently my plan for libvirt is to just talk directly
> 
> I'm toying with the idea, yes.  (Right now my toy runs in either native
> mode, using cgroupfs, or child mode, talking to a parent manager)  I'd
> love if someone else does it, but it needs to be done.
> 
> As I've said elsewhere in the thread, I see 2 problems to be addressed:
> 
> 1. The ability to nest the cgroup manager daemons, so that a daemon
> running in a container can talk to a daemon running on the host.  This
> is the problem my current toy is aiming to address.  But the API it
> exports is just a thin layer over cgroupfs.

 cool!  that's funny, that sounds exactly like what i asked if you
 could provide, and it turns out that you already did :)

 so, in theoorryy..... you could have this:

 * run the service on top of /dev/cgroups, republishing [a subset?] as
   /run/cgroups and some other parts as /run/cgroups2

 * have PID1, instead of going directly to /dev/cgroups, to go to
   /run/cgroups *instead*.

 * have lxc, instead of going directly to /dev/cgroups, to go to
   /run/cgroups2 *instead*.

 the problem: as lennart mentions, PID1s such as systemd may be expecting
 to manage the setup of cgroups - entirely - for security or other
 initialisation reasons - *before* even the service that you've created,
 serge, is allowed to run.

 and *that's* why i suggested the idea of following what SE/Linux has
 done, which is to have policy files that compile down to a set of
 permissions that the (various) managers can and cannot do.  bits of
 cgroup that they are and are not permitted to manage.

 flat at the kernel implementation level; hierarchical (or other)
 at the "compile-the-policy-file" level.

 l.

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