More MCS

[Gene Czarcinski]

I tried seting a category on a directory in /tmp and then (with touch) 
creating a file under that directory.  So far so good.

I then ssh'ed into the system as another user which does not have those 
categories defined in seusers.  This user could access the file.  This sounds 
like a bug to me.

Also, is there a way that a category value can be propogated to all 
files/directories below it?

Gene

[Stephen Smalley]

On Mon, 2005-10-31 at 14:49 -0500, Gene Czarcinski wrote:
>  I tried seting a category on a directory in /tmp and then (with
> touch) 
>  creating a file under that directory.  So far so good.
>  
>  I then ssh'ed into the system as another user which does not have those 
>  categories defined in seusers.  This user could access the file.  This sounds 
>  like a bug to me. 
Looks like the MCS constraints (as defined in policy/mcs) only constrain
access to files, not directories, presently (and this is noted in a
comment in that file, so it seems to be intentional).  They do appear to
work correctly for files.  Use of categories on directories doesn't seem
to be supported at present under MCS.

>  Also, is there a way that a category value can be propogated to all 
>  files/directories below it? 
Hmmm...the current MLS logic inherits from the process'
effective/current/low level rather than from the parent directory.

-- 
Stephen Smalley
National Security Agency

[Gene Czarcinski]

On Monday 31 October 2005 15:06, Stephen Smalley wrote:
>  On Mon, 2005-10-31 at 14:49 -0500, Gene Czarcinski wrote:
>  > I tried seting a category on a directory in /tmp and then (with touch)
>  > creating a file under that directory.  So far so good.
>  >
>  > I then ssh'ed into the system as another user which does not have those
>  > categories defined in seusers.  This user could access the file.  This
>  > sounds like a bug to me.
>
>  Looks like the MCS constraints (as defined in policy/mcs) only constrain
>  access to files, not directories, presently (and this is noted in a
>  comment in that file, so it seems to be intentional).  They do appear to
>  work correctly for files.  Use of categories on directories doesn't seem
>  to be supported at present under MCS. 
Yes, files work but not directories ... this is not intuitive (not expected).

>  > Also, is there a way that a category value can be propogated to all
>  > files/directories below it?
>
>  Hmmm...the current MLS logic inherits from the process'
>  effective/current/low level rather than from the parent directory. 
Whether MCS or MLS, if a user without the category/compartment can "blast 
through" the directory, this will be unexpected behavior.

Gene

[James Morris]

On Mon, 31 Oct 2005, Stephen Smalley wrote:

>  Looks like the MCS constraints (as defined in policy/mcs) only
> constrain
>  access to files, not directories, presently (and this is noted in a
>  comment in that file, so it seems to be intentional).  They do appear to
>  work correctly for files.  Use of categories on directories doesn't seem
>  to be supported at present under MCS. 
MCS is initially for files only, although it could be extended to 
directories if it makes sense.

What does it mean to say that /tmp/foo is "Company Confidential" ?  If the 
files under that directory are not all labeled with that category, they'll 
lose the MCS protection if copied or moved.  I think we really want to 
make sure that that each file is correctly labeled under MCS and not 
depend on parent directories, and not have to think about label 
inheritance semantics.

My view is that the MCS label is a security category explicitly assigned 
to a file, and should not change unless the user again explicitly changes 
it.  The label itself and its meaning have no hierarchical properties.


- James
-- 
James Morris
<jmorris(a)namei.org&gt;

[Stephen Smalley]

On Tue, 2005-11-01 at 10:57 -0500, James Morris wrote:
>  MCS is initially for files only, although it could be extended to 
>  directories if it makes sense.
>  
>  What does it mean to say that /tmp/foo is "Company Confidential" ?  If the 
>  files under that directory are not all labeled with that category, they'll 
>  lose the MCS protection if copied or moved.  I think we really want to 
>  make sure that that each file is correctly labeled under MCS and not 
>  depend on parent directories, and not have to think about label 
>  inheritance semantics.
>  
>  My view is that the MCS label is a security category explicitly assigned 
>  to a file, and should not change unless the user again explicitly changes 
>  it.  The label itself and its meaning have no hierarchical properties. 
I understand this POV, but I'm not sure it will translate well to how
people want to apply protection to their data.  On the other hand,
directory hierarchy-based protection often doesn't map well to the
desired security properties either, and does leave one open to aliasing
(via hard links or bind mounts) as well as relocation.

In any event, we might want to generalize the mls_compute_sid logic to
support either case, driven by the configuration, so that we can later
support such directory-based inheritance for MCS if desired without
having to patch the SELinux module.

-- 
Stephen Smalley
National Security Agency