about security contexts for objects

about security contexts for objects

[Giorgio Zanin]

I received good answer every time I posted to this mailing list, so I 
try this time too.

I am trying to get a formal model of the SELinux configuration language, 
in order to infer some properties of the system from a given configuration.
The first property I am interested in is about the access of a given 
(security context for a) subject to a given (security context for an) 
object.
A security context has three components: a "user", a "role" and a 
"type". Not all of the combinations of values for these components are 
generally allowed in the system; it depends on configuration rules. I 
call "valid" asecurity context that is allowed to be attached to a 
process or to a generic object. My problem is  how to determine valid 
security contexts.

First of all I noticed (or at least I thought) it is possible to define 
the set of all valid security contexts for subjects (process) in the 
following way:

- U is the set of all the "user" components for a security context. I 
can building up U, just examining all of the rules  as
user u roles {r1 r2 ...};

- R(u) is the set of all of the authorized roles for a given "user" u. 
It is possible to build up the set with the same rules as above

T is the set of all types, defined by rules as
type t;

T(r) is the set of domains a given role r can enter. It is possible to 
build up the set examining all of the rules as
role r types {t1 t2 ...};

So, now, the set of all possible security contexts for a subject can be 
modeled by

S = { (u,r,t) belonging to UxR(u)xT(r) }.

I can know all the valid security contexts for a process (elements of S) 
just looking at three kinds of configuration rules.

What I need now is something similar for object security contexts. The 
"role" component of such a security context is trivially "object_r". 
What about "user" and "type" components?

I thought it would be useful to define a set of valid security contexts 
with respect to a given object class.
For example, O(file) could be the set of all the valid security contexts 
for files, O(socket) the set of all the valid security contexts for 
sockets and so on, for each of the 29 object classes defined. Obviously, 
O(process) would be S.

Is it possible to define O(c) (c=a given object class different from 
"process") just looking at some configuration rules?
If I look at the file context configuration, I can get some elements of 
O(file) and O(dir), but I think I can't catch all of them.

type_transition rules could be useful  to catch some (but just some) 
elements of O(c), for a given generic class c.

So the best choice seems to be looking at access vector rules; with a 
rule as

allow A B : C P

I can argue B is a good "type" component for an object of class C. Can I 
catch all the valid "type" components in this way?

About "user" components for an object, maybe anyone is ok.

Anyone can help me in doing this?


Thank you in advance, and sorry for my bad English. I hope I have been 
at least a little clear :P

Giorgio


--
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: about security contexts for objects

[Russell Coker]

On Fri, 23 May 2003 00:10, Giorgio Zanin wrote:
> A security context has three components: a "user", a "role" and a
> "type". Not all of the combinations of values for these components are

The definition you give for the allowed combinations is accurate.

Also you should note that when a machine is in "permissive mode" processes can 
run in security contexts that are not permitted.  Toggling the machine to 
"enforcing mode" will destroy those security contexts and make the processes 
unlabelled (and unable to do anything useful).

> What I need now is something similar for object security contexts. The
> "role" component of such a security context is trivially "object_r".
> What about "user" and "type" components?

"user" is by default the identity of the user who created the object.  However 
certain processes are allowed to change the identity.  Eventually I will 
patch setfiles so that when it applies contexts to user home directories it 
will assign the "user" field correctly.  If the user field in the object 
security contexts matches that of a process then the process may be permitted 
to change the type of the object (see the constraints file - things are 
actually more complex than this).

> I thought it would be useful to define a set of valid security contexts
> with respect to a given object class.
> For example, O(file) could be the set of all the valid security contexts
> for files,

Which is all possible users and all possible types.  Although the policy may 
prohibit a certain user from having a process in a domain that can create a 
file of a particular type (it may even prohibit any domain from creating or 
writing to such a file) that does not prevent the file from keeping it's 
label.  For example if I change the user "john" from the role staff_r to the 
role user_r then the files with label john:object_r:staff_home_t will keep 
their label (and be inaccessible to John).

> Is it possible to define O(c) (c=a given object class different from
> "process") just looking at some configuration rules?
> If I look at the file context configuration, I can get some elements of
> O(file) and O(dir), but I think I can't catch all of them.

Look at the policy for all types that have the attribute file_type, that 
should catch all of them.

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

Re: about security contexts for objects

[Stephen Smalley]

On Thu, 2003-05-22 at 12:35, Russell Coker wrote:
> > Is it possible to define O(c) (c=a given object class different from
> > "process") just looking at some configuration rules?
> > If I look at the file context configuration, I can get some elements of
> > O(file) and O(dir), but I think I can't catch all of them.
> 
> Look at the policy for all types that have the attribute file_type, that 
> should catch all of them.

Not all of them.  The file_type attribute is limited to files associated
with conventional (disk-based) filesystems and is used in allow rules
permitting the association of such types with those filesystems.  It
doesn't cover types associated with pseudo filesystems.

Giorgio's suggestion of determining the set of possible file types by
inspection of the set of allow rules where a file class is used seems
reasonable.

-- 
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: about security contexts for objects

[Giorgio Zanin]

Stephen Smalley wrote:

>>Look at the policy for all types that have the attribute file_type, that 
>>should catch all of them.
>>

Actually file_type, as it is just an attribute with no semantics with 
respect to the configuration language, is not the thing I would look at.
I mean, attributes are just names associated with types with no 
semantics from a language point of view. What I need is something with 
semantics in the configuration language context.
I wouldn't use attributes values fot infering any property of a 
configuration, becouse I can think at an attribute just as a collection 
of types (attributes are useful but they are not necessary).

>>Not all of them.  The file_type attribute is limited to files associated
>>with conventional (disk-based) filesystems and is used in allow rules
>>permitting the association of such types with those filesystems.  It
>>doesn't cover types associated with pseudo filesystems.
>>
what are exactly all the kinds of pseudo files? Do they cover every  
object class  other than  file-related ones (file, filesystem, dir, 
fifo_file, ...) and process?

Giorgio



--
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: about security contexts for objects

[Stephen Smalley]

On Fri, 2003-05-23 at 04:09, Giorgio Zanin wrote:
> Stephen Smalley wrote:
> >>Not all of them.  The file_type attribute is limited to files associated
> >>with conventional (disk-based) filesystems and is used in allow rules
> >>permitting the association of such types with those filesystems.  It
> >>doesn't cover types associated with pseudo filesystems.
> >>
> what are exactly all the kinds of pseudo files? Do they cover every  
> object class  other than  file-related ones (file, filesystem, dir, 
> fifo_file, ...) and process?

No.  Pseudo files (e.g. /proc entries, devpts entries) have one of the
file classes.  So your approach of checking all allow rules that involve
a file class will capture these kinds of files as well as conventional
files, unlike the file_type attribute.

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