Detail description of some projects in TO DO list page

Detail description of some projects in TO DO list page

[nguyen thai]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1179 bytes --]

Re: Detail description of some projects in TO DO list page

[Stephen Smalley]

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.

Re: Detail description of some projects in TO DO list page

[nguyen thai]

On Wed, Feb 12, 2014 at 9:17 PM, Stephen Smalley <sds@tycho.nsa.gov> 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.

Thanks,
Thai

Re: Detail description of some projects in TO DO list page

[Paul Moore]

On Monday, March 10, 2014 02:31:29 PM nguyen thai wrote:
> On Wed, Feb 12, 2014 at 9:17 PM, Stephen Smalley <sds@tycho.nsa.gov> 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

Re: Detail description of some projects in TO DO list page

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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@tycho.nsa.gov>
>> 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/

iEYEARECAAYFAlMfCO0ACgkQrlYvE4MpobMEDQCfSB5J7Vgsq5rdJqLWIjej3n3+
x9UAoJoGLKWW2YSypX23dc9eQ6kIJbK1
=+aPS
-----END PGP SIGNATURE-----

Re: Detail description of some projects in TO DO list page

[nguyen thai]

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?

On Tue, Mar 11, 2014 at 8:00 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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@tycho.nsa.gov>
>>> 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/
>
> iEYEARECAAYFAlMfCO0ACgkQrlYvE4MpobMEDQCfSB5J7Vgsq5rdJqLWIjej3n3+
> x9UAoJoGLKWW2YSypX23dc9eQ6kIJbK1
> =+aPS
> -----END PGP SIGNATURE-----

Re: Detail description of some projects in TO DO list page

[Daniel J Walsh]

-----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@redhat.com> 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@tycho.nsa.gov> 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-----