MCS read only cats

MCS read only cats

[Michal Svoboda]

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

Hello,

I have been thinking of how to best implement a feature called read only
categories. That is, if we have a file with say c2, then c2 folks would
have full access (given by TE rules), but also there would be a category
called r2 (or c512+2 = c514 or whatever), that would be given read only
access to the file.

It seems to me that an implementation would ideally deal with a simple
MLS constrain or constrain relaxation. The reference policy constrains
file reading thus:

mlsconstrain file { read ioctl lock execute execute_no_trans }
        (( h1 dom h2 ) or ( t1 == mcsreadall ) or ( t2 == domain ));

How would one say 'also allow rN if file is cN'? So far I only came up
with an enumeration like so:

           (h1 dom r0 and h2 == c0)
	or (h1 dom r1 and h2 == c1)
	or (...1022 more)

Which seems ugly and perhaps such a mammoth expression would hog the
system too much. Moreover it seems it would be very difficult to
accomodate this enumeration for h2 == { c0, c1 } and beyond.

Does anyone have any better tips?

Michal Svoboda


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MCS read only cats

[Michal Svoboda]

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

Michal Svoboda wrote:
> I have been thinking of how to best implement a feature called read only
> categories.
> [...]

I got no replies to this topic... is that such an outrageous thing?

Regards,
Michal Svoboda

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MCS read only cats

[Chad Sellers]

On 11/3/09 6:45 AM, "Michal Svoboda" <michal.svoboda@agents.felk.cvut.cz>
wrote:

> Hello,
> 
> I have been thinking of how to best implement a feature called read only
> categories. That is, if we have a file with say c2, then c2 folks would
> have full access (given by TE rules), but also there would be a category
> called r2 (or c512+2 = c514 or whatever), that would be given read only
> access to the file.
> 
> It seems to me that an implementation would ideally deal with a simple
> MLS constrain or constrain relaxation. The reference policy constrains
> file reading thus:
> 
> mlsconstrain file { read ioctl lock execute execute_no_trans }
>         (( h1 dom h2 ) or ( t1 == mcsreadall ) or ( t2 == domain ));
> 
> How would one say 'also allow rN if file is cN'? So far I only came up
> with an enumeration like so:
> 
>            (h1 dom r0 and h2 == c0)
> or (h1 dom r1 and h2 == c1)
> or (...1022 more)
> 
> Which seems ugly and perhaps such a mammoth expression would hog the
> system too much. Moreover it seems it would be very difficult to
> accomodate this enumeration for h2 == { c0, c1 } and beyond.
> 
Michal,

You probably didn't get any responses because no one has a good idea of how
you could do this. The MLS engine (which is what powers MCS) was not
designed to do what you have in mind.

You're plan above will not work because you cannot express the constraints
as you've written them. You cannot single out specific categories in
mlsconstrain statements as you've tried to do. You are limited to
expressions about the high and low portions of the MLS field as a whole.

I'm sorry I don't know of a good way to accomplish what you're looking for.
You might be able to do something similar with a large enumeration in TE,
but that doesn't sound like what you're looking for. Perhaps someone else
will think of a creative way to use the MLS engine to do what you want, but
I don't know of one.

Thanks,
Chad Sellers


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: MCS read only cats

[Russell Coker]

On Thu, 12 Nov 2009, Chad Sellers <csellers@tresys.com> wrote:
> On 11/3/09 6:45 AM, "Michal Svoboda" <michal.svoboda@agents.felk.cvut.cz>
> > I have been thinking of how to best implement a feature called read only
> > categories. That is, if we have a file with say c2, then c2 folks would
> > have full access (given by TE rules), but also there would be a category
> > called r2 (or c512+2 = c514 or whatever), that would be given read only
> > access to the file.
>
> You probably didn't get any responses because no one has a good idea of how
> you could do this. The MLS engine (which is what powers MCS) was not
> designed to do what you have in mind.

Currently we don't support ranges on files, but we can change policy to allow 
it.  You could have something like the following:

mlsconstrain file { read }
        (( h1 dom l2 ) or ( t2 == domain ) or ( t1 == mlsfileread ));

mlsconstrain file { create relabelto }
        (( h1 dom h2 ) and ( l1 dom 12 ));

So (h1 dom h2) grants write access and (l1 dom l2) grants read access.


Now you could also implement that as (l1 dom l2) grants write access and (h1 
dom h2) grants read access if you wanted to control the release of 
information as opposed to controlling modification of system state.


But generally read-only files are implemented with new types.  I do that on 
the custom policy for my SE Linux Play Machine.

-- 
Russell Coker <russell@coker.com.au>
http://etbe.coker.com.au/          My Blog
http://etbe.coker.com.au/category/security/  My Security blog posts
http://www.coker.com.au/selinux/play.html  My Play Machine, root PW "SELINUX"


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: MCS read only cats

[Michal Svoboda]

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

Russell Coker wrote:
> Currently we don't support ranges on files, but we can change policy
> to allow it.  You could have something like the following:
> 
> mlsconstrain file { read }
>         (( h1 dom l2 ) or ( t2 == domain ) or ( t1 == mlsfileread ));
> 
> mlsconstrain file { create relabelto }
>         (( h1 dom h2 ) and ( l1 dom l2 ));

Hello,

thanks for the tip. Actually I had the same idea yesterday! Only that I
thought of 

mlsconstrain file { create relabelto }
         (( h1 dom h2 ) and ( h1 dom l2 ));
	                      ^

because in my MCS schema users usually have low = s0.

What exactly do you mean by not supporting ranges on files? Normally MCS
has a constrain on create/relabelto such as h2 eq l2, but I think if the
constrain is relaxed in the abovementioned fashion then there would be
no other problems? (I have seen multiranged files in the MLS policy...)

> But generally read-only files are implemented with new types.  I do
> that on the custom policy for my SE Linux Play Machine.

Well, what I want is to give users one login that maps to a generic
identity (say, user_u), but control their access to file of various
projects via MCS categories.

Now, if I had read only and read/write TE rules, I can imagine giving
every user 2 accounts, of which one would result in a shell that is
confined to read only operations, but has more MCS cats, but I can't
imagine how would I accomplish that with one account.

Or I could create a separate selinux user for everyone and by some
wicked macro machinery give that user the appropriate TE types and rules
for every project, but that seems to me like a lot of mess and generally
asking for trouble.

Regards,
Michal Svoboda

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: MCS read only cats

[Russell Coker]

On Thu, 12 Nov 2009, Michal Svoboda <michal.svoboda@agents.felk.cvut.cz> 
wrote:
> Russell Coker wrote:
> > Currently we don't support ranges on files, but we can change policy
> > to allow it.  You could have something like the following:
> >
> > mlsconstrain file { read }
> >         (( h1 dom l2 ) or ( t2 == domain ) or ( t1 == mlsfileread ));
> >
> > mlsconstrain file { create relabelto }
> >         (( h1 dom h2 ) and ( l1 dom l2 ));
>
> thanks for the tip. Actually I had the same idea yesterday! Only that I
> thought of
>
> mlsconstrain file { create relabelto }
>          (( h1 dom h2 ) and ( h1 dom l2 ));
> 	                      ^
>
> because in my MCS schema users usually have low = s0.

That will work too.  Lots of things will work, you just have to decide which 
is most appropriate given your security goals.  If anyone has given much 
thought to implementing read-only files with MCS they don't seem to have 
written about it publicly, so this is all new.

> What exactly do you mean by not supporting ranges on files? Normally MCS
> has a constrain on create/relabelto such as h2 eq l2, but I think if the
> constrain is relaxed in the abovementioned fashion then there would be
> no other problems? (I have seen multiranged files in the MLS policy...)

Yes, it's an arbitrary constraint.  Most people think that MCS is complex 
enough without ranged files.

> > But generally read-only files are implemented with new types.  I do
> > that on the custom policy for my SE Linux Play Machine.
>
> Well, what I want is to give users one login that maps to a generic
> identity (say, user_u), but control their access to file of various
> projects via MCS categories.

That is pretty common, but not with read-only vs read-write restrictions.

> Now, if I had read only and read/write TE rules, I can imagine giving
> every user 2 accounts, of which one would result in a shell that is
> confined to read only operations, but has more MCS cats, but I can't
> imagine how would I accomplish that with one account.

One Unix UID can have multiple SE Linux contexts.  The mapping of Unix account 
name to UID doesn't have to be 1:1.  But if you have multiple Unix accounts 
with the same UID then tools start to break.

Another possibility to consider is to give some file types an exclusion for 
read checks in the constraints.  That would mean that anyone could read them 
if the TE rules permit but MCS levels constrain write access.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: MCS read only cats

[Michal Svoboda]

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

Russell Coker wrote:
> That will work too.  Lots of things will work, you just have to decide
> which is most appropriate given your security goals.  If anyone has
> given much thought to implementing read-only files with MCS they don't
> seem to have written about it publicly, so this is all new.

Okay then I will implement this and see how it works.

> One Unix UID can have multiple SE Linux contexts.  The mapping of Unix
> account name to UID doesn't have to be 1:1.  But if you have multiple
> Unix accounts with the same UID then tools start to break.

Uh. They may not break that much but it will still give those people 2
accounts to use, be it usernames or selinux users; the UID is the least
relevant here. In fact, the beauty of MCS is that I could map everyone
to UID 0 and data access protection would still work as expected. Some
apps tend to derive usernames for audit purposes from getuid(), though,
so that would be a minor annoyance.

> Another possibility to consider is to give some file types an
> exclusion for read checks in the constraints.  That would mean that
> anyone could read them if the TE rules permit but MCS levels constrain
> write access.

Fair enough, but actually I need to provide three levels of access,
"none", "read only" and "full". The low/high range trick works here, but
I wonder if it would still be applicable if I wanted for example to add
a "create and append only" in between.

Michal Svoboda

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]