LWN.net Logo

Getting Started with Multi-Category Security (MCS)

James Morris has put up a look at multi-category security from an administrator's point of view. "In a corporate environment, categories could be used to identify documents confidential to specific departments, or being covered under certain NDAs. So, when jose prepares a report on payroll statistics for the month, he can label it as 'Payroll', which will not be accessible by lara, who only has access to the 'Finance' category."
(Log in to post comments)

Getting Started with Multi-Category Security (MCS)

Posted Jan 20, 2006 16:35 UTC (Fri) by jimmybgood (guest, #26142) [Link]

For those of you who are not running FC5 and do not have SELinux on your system, you can accomplish the same objectives with groups.

First set everyone's umask to 006 and make sure everyone's primary groups is unique to them. Like user bozo is in primary group bozo.

Then add groups for categories like follows:

groupadd cmp_conf
groupadd marketing

and the same for the other categories.

Add members to their appropriate groups with usermod or some GUI frontend like kusers.

After the document is created, issue

chgrp cmp_conf testfile.txt

As near as I can tell this accomplishes the same goal as the example in the MCS article.

Getting Started with Multi-Category Security (MCS)

Posted Jan 20, 2006 16:59 UTC (Fri) by sethg (guest, #14970) [Link]

If I understand SELinux correctly, an administrator can set things up so that when a document is in, say the NDA_Yoyodyne category, the owner of the document cannot take it out of that category. Unix groups don't provide that level of security; if I own a document in the nda_yoyodyne group, nothing stops me from making it world-readable and letting Yoyodyne's competitors sneak a peek at it.

Getting Started with Multi-Category Security (MCS)

Posted Jan 21, 2006 5:18 UTC (Sat) by jamesm (guest, #2273) [Link]

That's correct, you could change the policy to enforce this behavior (which is getting closer to MLS), although MCS does not enforce that by default, as it is discretionary in nature.

Does the security category follow the data wherever it is copied?

Posted Jan 23, 2006 4:16 UTC (Mon) by xoddam (subscriber, #2322) [Link]

What's to stop the document owner from creating an empty document that
isn't in this category, then pasting in the relevant data?

Does the security category follow the data wherever it is copied?

Posted Jan 23, 2006 15:53 UTC (Mon) by jamesmrh (guest, #31622) [Link]

Nothing, it's a discretionary system.

Getting Started with Multi-Category Security (MCS)

Posted Jan 20, 2006 17:14 UTC (Fri) by kokopelli (guest, #11341) [Link]

Besides the permissions mentioned earlier, groups suffer from combinatorical explosion since a file can't be mapped to more than one Unix group. You need to have every possible combination of groups, so n business groups maps to 2^n Unix groups. The poor user could also find himself listed in thousands of groups. (In theory -- what's the actual limit?)

To be fair some combinations don't make sense. But managing that can quickly become overwhelming in itself.

Getting Started with Multi-Category Security (MCS)

Posted Jan 20, 2006 18:15 UTC (Fri) by JoeBuck (subscriber, #2330) [Link]

No, you don't need every possible combination of groups, because you won't need the vast majority of those groups. After all, there are over a billion possible subsets of 30 users, but if you don't have a billion files, you can't possibly use all of the groups.

You only need a group for each distinct subset of your users that need access to a particular file. Creating a new ACL would be equivalent to creating a new group.

Getting Started with Multi-Category Security (MCS)

Posted Jan 20, 2006 18:19 UTC (Fri) by smoogen (subscriber, #97) [Link]

To give an example of where this does not work exactly.

User Annie is in both group cmp_conf and marketing
User Bobbie is in group cmp_conf
User Charlie is in group marketing

User Bobbie can create a document called Foo about a possible product.
Annie copies Foo
to make sure Bobbie can edit it does a manual `group cmp_conf`
annie then works on a document for Charlie and does a manual
`group marketing`. She forgets to change her group and edits
Foo again which accidently leaves a backup file with
user Annie group Marketing that Charlie can read.

Charlies takes the file Foo~ and does a pre-release press release on a vapour ware product. Bobbie is pissed.

[This set of things happens all the times. The larger the corporation and the more interaction between groups.. the more cross pollution. In most of the time, there is some reason that Charlie actually thought he had a legitimate reason to read Foo~ [it got added to his folder etc.]] In an MCS environment.. Charlie might end up with said file in his folder but would not be able to read it.

Getting Started with Multi-Category Security (MCS)

Posted Jan 20, 2006 19:46 UTC (Fri) by madscientist (subscriber, #16861) [Link]

> to make sure Bobbie can edit it does a manual `group cmp_conf`
> annie then works on a document for Charlie and does a manual
> `group marketing`

I assume you mean 'newgrp cmp_conf' here; there's no "group" command in standard UNIX that I know of.

Of course, this is completely the wrong way to go about things and no one should use this method. You would never suggest that people use "newgrp <groupname>". Instead, Bobbie always leaves her group set to her personal group ("bobbie" or whatever). All new documents and backup files will be created with that group. When she wants to publish a document Foo so that the cmp_conf group can read it, she would use "chgrp cmp_conf Foo".

Of course you need to make sure that whatever editors you use properly manage group ownership and permissions; some editors make backup files by renaming the existing file then writing a new file with the original name; if your editor works like that you need to be sure that it preserves permissions on the new file, including group permissions. But, any editor that works like that will already have solved this problem (it would be too annoying to work any other way).

Getting Started with Multi-Category Security (MCS)

Posted Jan 20, 2006 19:51 UTC (Fri) by madscientist (subscriber, #16861) [Link]

To follow up, the place where traditional group permissions really falls down is that any given file can belong to only one group. That means you will need a separate group for any combination of users that have a unique security requirement. As was pointed about above, this is obviously significantly less in practice than every possible combination of users, but it can still be annoying. What if you wanted Foo to be readable by all the people in the cmp_conf group AND the people in the marketing group? Or all the people in finance AND the people in payroll AND the people in marketing?

Etc.

ACLs let you share files with multiple groups. But != MAC.

Posted Jan 20, 2006 22:11 UTC (Fri) by dwheeler (guest, #1216) [Link]

In traditional Unix systems, a file can't belong to more than one group. But many systems support POSIX ACLs, which let you set access control values for different groups. On a Linux system, type "man setfacl". The setfacl command will let you set a given file so it can be read (or written) by multiple people, or groups. But this is different than MAC-like stuff, which is what SELinux can do. In setfacl, just like chmod, anyone who can read a file can copy it somewhere else, to anyone else. On a MAC system, the ADMIN can make that extremely hard to do (you can't do it directly... you may have to print it and scan it back in, for example).

"It's a very simple system:"

Posted Jan 21, 2006 6:22 UTC (Sat) by muwlgr (guest, #35359) [Link]

"to access a file, a user needs to be assigned to all of the categories with which the file is labeled."

Author said so. Note keyword "all".
That's how it is different from multiple-groups approach.

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds