All of lore.kernel.org
 help / color / mirror / Atom feed
* Basic question on policy design
@ 2003-12-03 15:49 Dhruv Gami
  2003-12-03 22:11 ` Stephen Smalley
  2003-12-04 13:29 ` Frank Mayer
  0 siblings, 2 replies; 7+ messages in thread
From: Dhruv Gami @ 2003-12-03 15:49 UTC (permalink / raw)
  To: SELINUX

Hello Everyone,

I am trying to understand how  Type Enforcement has been implemented in 
SELinux, and am using the sample policy given with the SELinux packages 
as an example.

In the paper "Meeting Critical Security Objectives with SELinux", 
Stephen Smalley and Peter Loscocco say:

The TE Configuration file defines an extensible set of types. Using the 
allow statement, allowable permissions between pairs of types are 
specified for each object class.

allow type_1 type_2:class { perm_1 ... perm_n };

The meaning of this above rule is not too clear to me.
1. what exactly is the relationship between type_1 and type_2 ?
2. is the class associated with type_2 only ?
3. Are type_1 and type_2 interchangable in the above rule ?
4. is there any rule that type_1 should be subject and type_2 should be 
an object type ?

The structure of the policy rules is not very clear to me. Is there any 
documentation available which makes it clear ? maybe im missing 
something somewhere. any help in this regard would be greatly appreciated.

regards,
Dhruv Gami


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Basic question on policy design
  2003-12-03 15:49 Basic question on policy design Dhruv Gami
@ 2003-12-03 22:11 ` Stephen Smalley
  2003-12-04 13:29 ` Frank Mayer
  1 sibling, 0 replies; 7+ messages in thread
From: Stephen Smalley @ 2003-12-03 22:11 UTC (permalink / raw)
  To: Dhruv Gami; +Cc: SELINUX

On Wed, 2003-12-03 at 10:49, Dhruv Gami wrote:
> I am trying to understand how  Type Enforcement has been implemented in 
> SELinux, and am using the sample policy given with the SELinux packages 
> as an example.

I'd recommend reading Configuring the SELinux Policy, available
from http://www.nsa.gov/selinux/policy2-abs.html.

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: Basic question on policy design
  2003-12-03 15:49 Basic question on policy design Dhruv Gami
  2003-12-03 22:11 ` Stephen Smalley
@ 2003-12-04 13:29 ` Frank Mayer
  2003-12-04 20:18   ` Diyab
  1 sibling, 1 reply; 7+ messages in thread
From: Frank Mayer @ 2003-12-04 13:29 UTC (permalink / raw)
  To: 'Dhruv Gami', 'SELINUX'

By now you might have received several responses, but here are some pointers.
Basic documentation is sparse but others are developing some.  You can look on
our web site (www.tresys.com/selinux) for slides from a 3-day class we presented
a couple times for additional information; these slides are several months old
but generally accurate.

> The TE Configuration file defines an extensible set of types. Using
> the allow statement, allowable permissions between pairs of types are
> specified for each object class.
> 
> allow type_1 type_2:class { perm_1 ... perm_n };

type_1 is the source (subject or process) type and type_2 is the target
(object) type.  "class" is the object class pertaining to type_2 only.
For example:

	allow user_t bin_t : file {read execute };

generally means processes with the user_t type can have read and execute
permission for object instances of class file that have the bin_t type.  Of
course it's more complicated in the general case; you really have to learn by
trial the semantic meaning of all the various object classes and their
permissions.

> The meaning of this above rule is not too clear to me.
> 1. what exactly is the relationship between type_1 and type_2 ?

This specifies allowed access by the source type (type_1) to the
target type (type_2) for the specified object class[es] and 
permission[s].

> 2. is the class associated with type_2 only ?

Yes.  Generally speaking the object class of the source is typically
a process (subject), but in the network area it can be things like
messages.  Think process for source object class and you'll be right 
the vast majority of the time.

> 3. Are type_1 and type_2 interchangable in the above rule ?

No.

> 4. is there any rule that type_1 should be subject and type_2 should
> be an object type ?

See above.

type_transition is even more difficult to understand semantically at first!  See
the referenced slides for some insights.  Good luck.

Frank



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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Basic question on policy design
  2003-12-04 13:29 ` Frank Mayer
@ 2003-12-04 20:18   ` Diyab
  2003-12-05  0:04     ` Russell Coker
  2003-12-09 17:05     ` Frank Mayer
  0 siblings, 2 replies; 7+ messages in thread
From: Diyab @ 2003-12-04 20:18 UTC (permalink / raw)
  To: mayerf; +Cc: 'Dhruv Gami', 'SELINUX'

Frank Mayer wrote:

>>3. Are type_1 and type_2 interchangable in the above rule ?
> 
> 
> No.
> 

This is not entirely true.  I've run into instances where running 
something like apache and postgresql on the same SELinux machine will 
require the ability to speak to one another.  So for process to process 
you might end up with something like:

allow httpd_t postgresql_t:tcp_socket { recffrom acceptfrom };
allow postgresql_t httpd_t:tcp socket { recvfrom acceptfrom };

Timothy,

-- 
I put instant coffee in a microwave and almost went back in time.
		-- Steven Wright


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Basic question on policy design
  2003-12-04 20:18   ` Diyab
@ 2003-12-05  0:04     ` Russell Coker
  2003-12-09 12:14       ` Timothy Wood
  2003-12-09 17:05     ` Frank Mayer
  1 sibling, 1 reply; 7+ messages in thread
From: Russell Coker @ 2003-12-05  0:04 UTC (permalink / raw)
  To: SE Linux

On Fri, 5 Dec 2003 07:18, Diyab <diyab@diyab.net> wrote:
> require the ability to speak to one another.  So for process to process
> you might end up with something like:

can_tcp_connect(httpd_t, postgresql_t)

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Basic question on policy design
  2003-12-05  0:04     ` Russell Coker
@ 2003-12-09 12:14       ` Timothy Wood
  0 siblings, 0 replies; 7+ messages in thread
From: Timothy Wood @ 2003-12-09 12:14 UTC (permalink / raw)
  To: russell; +Cc: SE Linux

Russell Coker wrote:

> On Fri, 5 Dec 2003 07:18, Diyab <diyab@diyab.net> wrote:
> 
>>require the ability to speak to one another.  So for process to process
>>you might end up with something like:
> 
> 
> can_tcp_connect(httpd_t, postgresql_t)
> 

I was not aware that existed.  It does seem to exactly what is needed. 
Thanks for pointing that out Russell.

Timothy,



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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: Basic question on policy design
  2003-12-04 20:18   ` Diyab
  2003-12-05  0:04     ` Russell Coker
@ 2003-12-09 17:05     ` Frank Mayer
  1 sibling, 0 replies; 7+ messages in thread
From: Frank Mayer @ 2003-12-09 17:05 UTC (permalink / raw)
  To: 'Diyab'; +Cc: 'Dhruv Gami', 'SELINUX'

>>> 3. Are type_1 and type_2 interchangable in the above rule ?
>> 
>> No.
> 
> This is not entirely true.  I've run into instances where running
> something like apache and postgresql on the same SELinux machine will
> require the ability to speak to one another.  So for process to
> process you might end up with something like:
> 
> allow httpd_t postgresql_t:tcp_socket { recffrom acceptfrom };
> allow postgresql_t httpd_t:tcp socket { recvfrom acceptfrom };

Just to be precise, for a given policy you may need to make access between two
types reciprocal as in the above example.  However, I stand by my answer to the
original question: one cannot interchange the source and target types in a given
allow rule with the two resultant rules having the same semantic meaning.

Frank



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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-12-09 17:05 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-03 15:49 Basic question on policy design Dhruv Gami
2003-12-03 22:11 ` Stephen Smalley
2003-12-04 13:29 ` Frank Mayer
2003-12-04 20:18   ` Diyab
2003-12-05  0:04     ` Russell Coker
2003-12-09 12:14       ` Timothy Wood
2003-12-09 17:05     ` Frank Mayer

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.