role orthogonality

role orthogonality

[Robert Bihlmeyer]

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

One thing that I still poorly understand is the interaction between
types and roles.

Am I right that roles are only relevant when transitioning, and not
during normal type enforcement?

It seems to me that we often want to break that orthogonality, so we
encode the role in the type (e.g. sysadm_tty_device_t vs
user_tty_device_t). I find this ugly, boring and repetitive -- exactly
the kind of thing that computers should shield us from. Wouldn't it be
possible to make the policy language grok these desires? Out of my
hat:

    rtype foo_t, domain;
    type foo_etc_t, file_type;
    rtype foo_files_t, file_type;

    allow foo_t self:process signal;
    allow foo_t foo_etc_t:file r_file_perms;
    allow foo_t foo_files_t:file rw_file_perms;

This is supposed to mean that foo_t and foo_files_t exist seperately
for every role, while there is only one foo_etc_t. Or you can think of
foo_t and foo_files_t having "hard" boundaries between roles.

So in this scenario user_r:foo_t may signal user_r:foo_t, but not
sysadm_r:foo_t; user_r:foo_files_t [1] may only be read/written by
user_r:foo_t, not sysadm_r:foo_t; but foo_etc_t can be read by foo_t
under any role.

It's probably desirable to allow more detailed specification as well:
    allow sysadm_r:foo_t user_r:foo_files_t:file rw_file_perms;
meaning that sysadm_r can access user_r's foo_files as well. (Yes we
run into colon overload problems here.)

Now, what's wrong with this naive proposal?


[1] Files would need to be able to hold roles, then.

-- 
Robbe

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

Re: role orthogonality

[Stephen Smalley]

On Sun, 2003-04-20 at 04:51, Robert Bihlmeyer wrote:
> One thing that I still poorly understand is the interaction between
> types and roles.
> 
> Am I right that roles are only relevant when transitioning, and not
> during normal type enforcement?

Yes, roles only come into play on process transitions, based on the role
allow rules and the constraints configuration.  Roles are merely a layer
of abstraction for grouping related domains together and assigning them
to users.  They can provide a limited form of boundary between sets of
domains (i.e. by limiting a user to certain roles, you bound the set of
domains he can reach), but even here, you are truly relying on TE to
deal with all possible interactions between those domains (i.e.
non-transition forms of interactions).

> It seems to me that we often want to break that orthogonality, so we
> encode the role in the type (e.g. sysadm_tty_device_t vs
> user_tty_device_t). I find this ugly, boring and repetitive -- exactly
> the kind of thing that computers should shield us from. 

This is actually a type derivation (sysadm_tty_device_t is a type
derived from sysadm_t and tty_device_t), not role encoding.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: role orthogonality

[Russell Coker]

On Sun, 20 Apr 2003 18:51, Robert Bihlmeyer wrote:
> This is supposed to mean that foo_t and foo_files_t exist seperately
> for every role, while there is only one foo_etc_t. Or you can think of
> foo_t and foo_files_t having "hard" boundaries between roles.

Probably the best way to do that would be in an object-oriented manner.  You 
could have a security "class" which defines local types.  Then the User class 
would be instantiated for user_t and sysadm_t.

You could implement this as a policy pre-processor which outputs code with 
name mangling that the checkpolicy tool can accept, in a similar manner to 
the C-front implementation of C++.

Things of a similar nature have been suggested before and the NSA people 
haven't seemed to like any of them.  But that doesn't prevent you from doing 
whatever you want.

Although I think that there's much less call for such things now than there 
used to be.  I think I've solved a lot of the annoying policy issues with M4 
macros, and I will probably improve it even more in the next few months.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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.