On Monday, March 10, 2014 02:31:29 PM nguyen thai wrote: > On Wed, Feb 12, 2014 at 9:17 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > On 02/11/2014 09:24 PM, nguyen thai wrote: > >> Hi everyone, > >> > >> I have started my study in SELinux recently. I found some projects in TO > >> DO > >> list page were really interesting. Can anyone give me more details > >> (what's > >> problem now? it's effects or drawbacks) of one of following projects or > >> any > >> other projects that i can start to work on? > >> > >> - Investigate security policy for cgroups > >> - CIFS support for single-context clients > >> - Real device labeling and access control > >> > >> Thank you very much. > > > > That TODO list is old and not actively maintained, so it may be better > > to look at recent mailing list archives to see areas where you can > > contribute most effectively. Also look for recent discussions of > > selinux in the linux-security-module and linux-kernel mailing list > > archives. > > > > On the cgroup item, it should be possible to support finer-grained > > labeling of cgroup files now that cgroup supports xattrs, but it will > > require a small kernel change (similar to the changes previously made > > for sysfs and rootfs; need to generalize that), and thereby enabling > > policy control over specific cgroup files. There may also be work > > required inside the cgroup code to add security hooks and permission > > checks for MAC; that would require analysis of the cgroup > > implementation, existing DAC checks, ways in which they can permit > > different security labels to interact/interfere with each other, etc. > > Hi, > I have spent several weeks on digging into cgroup code and its problems. > As i understand, there are several reasons why you want to enable MAC > checks over specific cgroup file: > > + The cgroup interface is filesystem, means that users can change > permissions on subdirectories and > give access to a non-privileged security domain, ie non-root users. > Leading to an individual application > can interact directly with the cgroup filesystem. It ends up > exposing control knobs which are tightly > coupled to kernel implementation details right into lay binaries > and scripts directly used by end users. > > + The cgroups trees are a shared resource. Many applications can use > it simultaneously. So they can > conflicts with others. Ex, move tasks, delete or move the cgroups > that belong to other applications. > > MAC check can improve some of the cgroup problems. But I've heard that > cgroup and systemd developers have > been making really big changes to fix these cgroup problems. As they > described here > http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html > or http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > They are creating a centralized userland authority which takes full > ownership of the cgroup filesystem > interface, and makes policy decisions based on configuration and > requests. This may solve above problems. > > So does implementing MAC checks on cgroup can is needed anymore? Can > it help improving some other problems? > I'm getting stuck finding something to do here. I think it might make sense to first look at what you are hoping to accomplish, not in terms of code/hooks/etc., but rather high-level access controls. Try not to focus on the implementation to start, for example: * What can one do with cgroups, how are they managed? Of all the different configuration/management operations, which are significant from a security perspective? * For each of these operations, what is the SELinux subject and object? What would the security policy look like? Does it make sense? ... and go from there. -- paul moore www.paul-moore.com _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
