-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/11/2014 11:09 PM, nguyen thai wrote: > Until now, any processes with root privilege can change cgroup settings. > Others cannot. Definitely we can grant more permissions for processes in a > cgroup to edit its subgroup. But I think there will be a problem. > > Cause there are many processes in a cgroup, so maybe more than one want to > edit the same subgroup. Or Change a subgroup settings will definitely > affect the other subgroups which an other process want to control. That > will cause a conflict. Or a malware or bad-behavior program can limit other > subgroup so it can get more resource. > > To solve this problem, we need an arbitrator. And is Selinux too low level > to take this role? > I don't think so. If I had a container running as svirt_lxc_net_t:s0:c1,c2 and had labels on my cgroup subgroup as svirt_sandbox_file_t:s0:c1:c2 I could allow it to write and prevent it from attacking a different container cgroup that was labeled as svirt_sandbox_file_t:s0:c3,c4 > On Tue, Mar 11, 2014 at 8:00 PM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote: > On 03/10/2014 05:45 PM, Paul Moore wrote: >>>> 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. >>>> > > I would see a possible security goal, would be with containers. Could I > run a container within a group of cgroups and allow the processes within > the cgroup to further limit the cgroups. > > IE If I run a container with a max of 2Gig or memory, could a process > within the container, further limit a child process to 1Gig of memory, and > not allow a process within the container to setup a cgroup with > 2Gig of > memory. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMgUJ0ACgkQrlYvE4MpobNbZwCgs+z3l/hRjlGIuiS2v6DxeLVV oXoAoKDkZeWgNS/bQ1yUiBZBPDJomWAQ =vqOF -----END PGP SIGNATURE----- _______________________________________________ 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.
