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
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.
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
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
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.
selinux@lists.fedoraproject.org