Multiple contexts

Multiple contexts

[Ivan Gyurdiev]

Why doesn't SElinux support multiple contexts per file?
It seems to me that this feature would be very useful. 
Is this technically not feasible?

I've been trying to get the following setup working on FC3 (rawhide):

/var/www/html.userX  - 
	virtual server for userX.mydomain labeled httpd_sys_content_t
/home/userX - 
	home folder for userX, exported via Samba (not yet, but
	it will be, once dwalsh puts in booleans for samba reading home)

/home/userX/webserver - symlink to /var/www/html.userX 

Now, /var/www/html.userX needs to be accessed both by smbd and httpd.
I need to label it with both samba_share_t and httpd_sys_content_t.

I have to edit the cryptic m4 policy file to add a type that's
accessible by both. Why is this necessary? Why can't selinux
either
	(1) Label the file with both contexts, and permit
	the operation if any context permits it

	or
		
	(2) Create a type with the properties of both
	with less user interaction (without needing to 
	modify the policy manually)

Since I'm unfamiliar with how SElinux works internally,
this might be a stupid question, but it seems to me that 
the user should not be required to understand how a policy
file works to label a file for use by two restricted programs.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Mon, Jan 10, 2005 at 01:50:49PM -0700, Ivan Gyurdiev wrote:
> Why doesn't SElinux support multiple contexts per file?
> It seems to me that this feature would be very useful. 
> Is this technically not feasible?
> 
> I've been trying to get the following setup working on FC3 (rawhide):
> 
> /var/www/html.userX  - 
> 	virtual server for userX.mydomain labeled httpd_sys_content_t
> /home/userX - 
> 	home folder for userX, exported via Samba (not yet, but
> 	it will be, once dwalsh puts in booleans for samba reading home)
> 
> /home/userX/webserver - symlink to /var/www/html.userX 
> 
> Now, /var/www/html.userX needs to be accessed both by smbd and httpd.
> I need to label it with both samba_share_t and httpd_sys_content_t.
 
 i understand the mindset of selinux enough now to be able to say that
 the recommended approach would be for you to create a file type
 samba_share_httpd_sys_content_t and then for you to modify the
 selinux policy to grant the programs requiring access to those
 filetypes in the samba.te and the apache.te policy files.

> I have to edit the cryptic m4 policy file to add a type that's
> accessible by both. Why is this necessary? Why can't selinux
> either

> 	(1) Label the file with both contexts, and permit
> 	the operation if any context permits it
> 
> 	or
> 		
> 	(2) Create a type with the properties of both
> 	with less user interaction (without needing to 
> 	modify the policy manually)
> 
> Since I'm unfamiliar with how SElinux works internally,
> this might be a stupid question, but it seems to me that 
> the user should not be required to understand how a policy
> file works to label a file for use by two restricted programs.

 yes, it does seem a little curious: taking NT security descriptors
 (actually VMS SDs) as an example, and ignoring the fact that NT/VMS
 SDs contain DAC (discretionary) ACLs - each ACL is just that - an
 access control LIST.

 whereas in NT, the SD contains ACLs and the ACLs can be extended,
 modified and edited (and are better understood!), SElinux turns things
 roundabout somewhat: providing a reference (handle) into a binary
 policy.

 what i _am_ aware of is that by having the policies in a structured
 language, formal analysis tools can be applied to make certain
 guarantees and proofs.

 in paranoid security environments, it's far more important
 to be able to prove that someone _could_ break in than to
 not _know_ if they could break in (!)

 i can only hazard a hazardous guess therefore that the more
 "normal" ACL system [that we are used to seeing] was rejected
 because it makes the formal proof methodology more difficult.

 *shrug*.  *clueless*.  anyone know?

 l.


--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Mon, Jan 10, 2005 at 11:23:12PM +0000, Luke Kenneth Casson Leighton wrote:

>  modified and edited (and are better understood!), SElinux turns things
>  roundabout somewhat: providing a reference (handle) into a binary
>  policy.

 ... that i do not know the exact details of but i do know it
 [binary policy] can be edited at runtime using tools that
 tresys have been developing and maintaining for some time now.

 l.


--
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: Multiple contexts

[Stephen Smalley]

On Mon, 2005-01-10 at 15:50, Ivan Gyurdiev wrote:
> Why doesn't SElinux support multiple contexts per file?
> It seems to me that this feature would be very useful. 
> Is this technically not feasible?
> 
> I've been trying to get the following setup working on FC3 (rawhide):
> 
> /var/www/html.userX  - 
> 	virtual server for userX.mydomain labeled httpd_sys_content_t
> /home/userX - 
> 	home folder for userX, exported via Samba (not yet, but
> 	it will be, once dwalsh puts in booleans for samba reading home)
> 
> /home/userX/webserver - symlink to /var/www/html.userX 
> 
> Now, /var/www/html.userX needs to be accessed both by smbd and httpd.
> I need to label it with both samba_share_t and httpd_sys_content_t.
> 
> I have to edit the cryptic m4 policy file to add a type that's
> accessible by both. Why is this necessary? Why can't selinux
> either
> 	(1) Label the file with both contexts, and permit
> 	the operation if any context permits it
> 
> 	or
> 		
> 	(2) Create a type with the properties of both
> 	with less user interaction (without needing to 
> 	modify the policy manually)
> 
> Since I'm unfamiliar with how SElinux works internally,
> this might be a stupid question, but it seems to me that 
> the user should not be required to understand how a policy
> file works to label a file for use by two restricted programs.

Don't confuse the user interface with the mechanism.  You can build the
user interface you describe in (2) on top of the existing mechanism, and
others are already working on higher level policy tools and languages.

-- 
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: Multiple contexts

[Stephen Smalley]

On Mon, 2005-01-10 at 15:50, Ivan Gyurdiev wrote:
> Why doesn't SElinux support multiple contexts per file?
> It seems to me that this feature would be very useful. 
> Is this technically not feasible?
> 
> I've been trying to get the following setup working on FC3 (rawhide):
> 
> /var/www/html.userX  - 
> 	virtual server for userX.mydomain labeled httpd_sys_content_t
> /home/userX - 
> 	home folder for userX, exported via Samba (not yet, but
> 	it will be, once dwalsh puts in booleans for samba reading home)
> 
> /home/userX/webserver - symlink to /var/www/html.userX 
> 
> Now, /var/www/html.userX needs to be accessed both by smbd and httpd.
> I need to label it with both samba_share_t and httpd_sys_content_t.
> 
> I have to edit the cryptic m4 policy file to add a type that's
> accessible by both. Why is this necessary? Why can't selinux
> either
> 	(1) Label the file with both contexts, and permit
> 	the operation if any context permits it

Because then policy would be encoded in the file attributes, not in a
centralized security policy.  Hence, one would be unable to analyze
information flow in the system based solely on the policy and would have
to also analyze the complete filesystem state, and that state is much
more subject to change at runtime than the policy itself (one would
hope).

-- 
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: Multiple contexts

[Stephen Smalley]

On Mon, 2005-01-10 at 18:23, Luke Kenneth Casson Leighton wrote:
>  i can only hazard a hazardous guess therefore that the more
>  "normal" ACL system [that we are used to seeing] was rejected
>  because it makes the formal proof methodology more difficult.

With ACLs, you have to traverse the entire filesystem state in order to:
1) determine what your policy truly is (and that policy can change
underneath you during your traversal),
2) apply any widespread changes in policy state.

Management and scalability nightmare.

-- 
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Tue, Jan 11, 2005 at 03:09:51PM -0500, Stephen Smalley wrote:
> On Mon, 2005-01-10 at 18:23, Luke Kenneth Casson Leighton wrote:
> >  i can only hazard a hazardous guess therefore that the more
> >  "normal" ACL system [that we are used to seeing] was rejected
> >  because it makes the formal proof methodology more difficult.
> 
> With ACLs, you have to traverse the entire filesystem state in order to:
> 1) determine what your policy truly is (and that policy can change
> underneath you during your traversal),
> 2) apply any widespread changes in policy state.
 
> Management and scalability nightmare.
 
 oh - ah.  yes, now it comes back to me.

 microsoft solved this problem partially in NT 3.5 - NT 4.0 by
 only reading the ACL on the file [or directory] and applying that.

 by the time that NT 5 [aka windeuuws teuu thousand, with NT being a
 trademark owned by Northern Telecom, aka Nortel and all] came around,
 this was considered utterly mad.

 recursion was added to ACLs - or "inheritance" - because to fix access
 to subdirectories and all contents you are required in NT 4.0 to change
 ALL permissions on ALL subdirectories and contents!

 basically you now have to traverse the directory tree right
 up to the mount point [as stephen says] in order to determine access
 rights, combining and checking permissions as you go.

 eeuuuw.

 ... was that what you were referring to stephen?

 l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
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: Multiple contexts

[Stephen Smalley]

On Tue, 2005-01-11 at 16:48, Luke Kenneth Casson Leighton wrote:
>  recursion was added to ACLs - or "inheritance" - because to fix access
>  to subdirectories and all contents you are required in NT 4.0 to change
>  ALL permissions on ALL subdirectories and contents!
> 
>  basically you now have to traverse the directory tree right
>  up to the mount point [as stephen says] in order to determine access
>  rights, combining and checking permissions as you go.
> 
>  eeuuuw.
> 
>  ... was that what you were referring to stephen?

No.  I'm simply referring to the fact that if your policy is encoded in
the file attributes themselves, as with ACLs, then you cannot analyze
the potential information flow among security equivalence classes in the
system (which is necessary if you want to ensure confidentiality or
integrity guarantees) without looking at all of the file attributes. 
Centralizing the policy allows you to analyze the potential information
flow separately, and organizing the set of subjects and objects into
security equivalence classes (types in TE, levels in MLS) makes the
system manageable (vs. per-object policy as with ACLs).

-- 
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Wed, Jan 12, 2005 at 09:00:49AM -0500, Stephen Smalley wrote:

> On Tue, 2005-01-11 at 16:48, Luke Kenneth Casson Leighton wrote:
> >  recursion was added to ACLs - or "inheritance" - because to fix access
> >  to subdirectories and all contents you are required in NT 4.0 to change
> >  ALL permissions on ALL subdirectories and contents!
> > 
> >  basically you now have to traverse the directory tree right
> >  up to the mount point [as stephen says] in order to determine access
> >  rights, combining and checking permissions as you go.
> > 
> >  eeuuuw.
> > 
> >  ... was that what you were referring to stephen?
> 
> No.  I'm simply referring to the fact that if your policy is encoded in
> the file attributes themselves, as with ACLs, then you cannot analyze
> the potential information flow among security equivalence classes in the
> system (which is necessary if you want to ensure confidentiality or
> integrity guarantees) without looking at all of the file attributes. 

 ... how about encoding the file attributes in the policy files,
 such that they are ACL-like?

 [i realise this is quite a radical change under-the-hood]

 if nothing else by having the means to apply a list of contexts
 [any of which may apply] to a file.

 the ultimate aim of which would be to make it easier for
 administrators to add permissions and programs without going
 through a complete policy rebuild / reload.


--
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 09:44, Luke Kenneth Casson Leighton wrote:
>  ... how about encoding the file attributes in the policy files,
>  such that they are ACL-like?

I don't follow your line of thinking.  The policy defines allowed
interactions among security equivalence classes (types for TE, levels
for MLS).  A file attribute (which is merely a tag identifying the
security equivalence class into which the file falls) is stored in the
filesystem, associated with the inode.  You don't want to move the
file->type associations into the policy; you want them bound to the real
objects and maintained properly at runtime.

>  the ultimate aim of which would be to make it easier for
>  administrators to add permissions and programs without going
>  through a complete policy rebuild / reload.

This functionality can all be built on top of the existing mechanism. 
And we already have some incremental steps in this direction:
- the conditional policy support developed by Tresys, included in the
mainline SELinux, and used extensively now in Fedora, allows
well-defined changes in policy based on policy boolean settings that can
be manipulated from userspace and controlled at fine granularity,
- the binary policy module support developed by Tresys allows policy
modules to be constructed, built, and distributed without requiring a
full policy source rebuild and providing proper dependency checking,
- the policy daemon being developed by Tresys will allow policy
management to be decomposed.

See the mailing list archives if you haven't already read about it. 
Obviously, there is much work to do in this space, and contributors are
welcome.

-- 
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 13:18, Luke Kenneth Casson Leighton wrote:
>  sorry.
> 
>  something simple:
> 
>  i am thinking along the lines of more than one file context being
>  associated with a file - that sort of thing.
> 
>  and permission being checked and allowed on either of the contexts.

I already explained why you don't want that - it puts the policy into
the filesystem state.

-- 
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Wed, Jan 12, 2005 at 10:00:47AM -0500, Stephen Smalley wrote:
> On Wed, 2005-01-12 at 09:44, Luke Kenneth Casson Leighton wrote:
> >  ... how about encoding the file attributes in the policy files,
> >  such that they are ACL-like?
> 
> I don't follow your line of thinking.  

 sorry.

 something simple:

 i am thinking along the lines of more than one file context being
 associated with a file - that sort of thing.

 and permission being checked and allowed on either of the contexts.

 in this way, someone can keep the default policy made for apache
 (both the .te and the .fc file)

 and can also create their own home-grown policy.

 the issue of creating a special "samba_apache_file_type_t" and
 deviating from two sets of standard policy files does seem...
 somewhat archaic.

 l.


--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Wed, Jan 12, 2005 at 01:03:02PM -0500, Stephen Smalley wrote:
> On Wed, 2005-01-12 at 13:18, Luke Kenneth Casson Leighton wrote:
> >  sorry.
> > 
> >  something simple:
> > 
> >  i am thinking along the lines of more than one file context being
> >  associated with a file - that sort of thing.
> > 
> >  and permission being checked and allowed on either of the contexts.
> 
> I already explained why you don't want that - it puts the policy into
> the filesystem state.
 
 i don't believe it does - or i am misunderstanding.

 having two policy files apache.fc and mymodifiedthing.fc which _both_
 have a file context for the same file / directory, such that the
 data that ends up in the security.selinux xattr is "apache_filetype_t,
 "mymodifiedthing_filetype_t" doesn't mean, in my book "policy is in
 filesystem state".

 ... does it?

 *lost*.

 l.


--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Wed, Jan 12, 2005 at 01:03:02PM -0500, Stephen Smalley wrote:
> On Wed, 2005-01-12 at 13:18, Luke Kenneth Casson Leighton wrote:
> >  sorry.
> > 
> >  something simple:
> > 
> >  i am thinking along the lines of more than one file context being
> >  associated with a file - that sort of thing.
> > 
> >  and permission being checked and allowed on either of the contexts.
> 
> I already explained why you don't want that - it puts the policy into
> the filesystem state.

 there is of course the other scheme which achieves the same end-result,
 but using customised m4 macro-based programs to do it: this scheme
 has been raised before.

 namely, to have your apache.fc file and your customthing.fc file,
 and to "spew forth" a combined apache_customthing_filetype_t with
 some macro preprocessing.

 then your apache.fc is unmodified, it's clean, it can be verified,
 upgraded etc...

 l.


--
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: Multiple contexts

[Ivan Gyurdiev]

And of course I forgot to cc list.
Sorry about the multiple mails.

> > I have to edit the cryptic m4 policy file to add a type that's
> > accessible by both. Why is this necessary? Why can't selinux
> > either
> > 	(1) Label the file with both contexts, and permit
> > 	the operation if any context permits it
> 
> Because then policy would be encoded in the file attributes, not in a
> centralized security policy.  Hence, one would be unable to analyze
> information flow in the system based solely on the policy and would have
> to also analyze the complete filesystem state, and that state is much
> more subject to change at runtime than the policy itself (one would
> hope).

Please explain this some more - Luke also seems confused about this
(unless I misunderstand). I don't understand how the change from one
context to multiple contexts stored per file translates into policy
being encoded in the file attributes.

It seems to me that this change would simply allow more accurate
association of the files with the proper security data.

It is still a centralized policy which decides whether to allow an
action or not - it just takes into consideration multiple contexts.
I am merely suggesting that when a security decision is necessary for
a file, all the contexts it is labeled with are provided by the
filesystem, and the security server makes a decision based on 
whether an access path (not sure of terminology here) exists
between the subject context and any object context. 

Your httpd policy describes what contexts httpd has access to.
Your samba policy describes what contexts smbd has access to.
This information is not stored in the filesystem somewhere - it's 
in the binary policy. Multiple contexts will simply allow
the user to more accurately specify the class of the object 
that you have to work with, with minimal interaction - it 
is fundamentally not a samba share, or httpd content, it is both,
and it seems the only sane thing to do is label it with both,
or something that's a mix of the two. I am interested in 
the easiest possible way to do this without playing with the policy.
Why should I be changing the policy? I should
only need to do that when I want to describe changes in 
security classes and relationships between them. What I want to do 
is simply mark data as belong to more than one existing class,
without changing either one.

So, it seems to me that userspace tools should provide
an easy way to mark a file for contexts it belongs to,
and internally selinux could still map this information
to a unique sid somehow. Is this possible?

I can imagine multiple contexts for processes would be useful
as well, although I can't come up with examples right now...

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 13:29, Luke Kenneth Casson Leighton wrote:
>  i don't believe it does - or i am misunderstanding.
> 
>  having two policy files apache.fc and mymodifiedthing.fc which _both_
>  have a file context for the same file / directory, such that the
>  data that ends up in the security.selinux xattr is "apache_filetype_t,
>  "mymodifiedthing_filetype_t" doesn't mean, in my book "policy is in
>  filesystem state".
> 
>  ... does it?
> 
>  *lost*.

The file_contexts configuration is not part of the kernel policy.  It is
only used by userspace to set the contexts for files upon installation,
to recheck the state of the filesystem against the initial labeling
state, or to restore portions of the filesystem to the initial labeling
state.

If you change the SELinux module to support a list of file contexts
within the security.selinux attribute, and change its policy engine to
allow access if any access is allowed to any one of those contexts, then
the only way to truly identify what information flow is possible in the
system is by checking the current security.selinux attributes of all
files in the system for such combinations and collapsing them to a
single security equivalence class for analysis purposes.  Think:  policy
says allow P1 F1:file read; allow P2 F2:file write;, policy analysis
says that there is no allowed information flow from P2 to P1, but
someone does a chcon -t F1,F2 foobar and now P2 can write to foobar and
P1 can read from it, so information flow is now possible.  If you want
to control information flow throughout the system to prevent leakage of
information or to protect trusted processes against being corrupted by
untrustworthy input, you can't ignore the issue.

-- 
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: Multiple contexts

[Stephen Bennett]

On Wed, 2005-01-12 at 13:11 -0700, Ivan Gyurdiev wrote:
> > Because then policy would be encoded in the file attributes, not in a
> > centralized security policy.  Hence, one would be unable to analyze
> > information flow in the system based solely on the policy and would have
> > to also analyze the complete filesystem state, and that state is much
> > more subject to change at runtime than the policy itself (one would
> > hope).
> 
> Please explain this some more - Luke also seems confused about this
> (unless I misunderstand). I don't understand how the change from one
> context to multiple contexts stored per file translates into policy
> being encoded in the file attributes.

AIUI, the issue is something like this: 

With only one type per file, it's possible to look at the policy and be
certain (for example) that domain1 can't affect domain2 in any way,
because there are no interactions allowed between the two, and the file
types they can access don't overlap. If you allow multiple contexts per
file, that ability goes out of the window, and you have to look at which
files have multiple contexts and what contexts they are before you can
figure out where information can and can't flow.

Of course I may be off here, and I may have missed more subtleties, but
that's the problem I can see with multiple types per file. Someone
correct me if I'm wrong here. :)


--
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 15:11, Ivan Gyurdiev wrote:
> Please explain this some more - Luke also seems confused about this
> (unless I misunderstand). I don't understand how the change from one
> context to multiple contexts stored per file translates into policy
> being encoded in the file attributes.
> 
> It seems to me that this change would simply allow more accurate
> association of the files with the proper security data.
> 
> It is still a centralized policy which decides whether to allow an
> action or not - it just takes into consideration multiple contexts.
> I am merely suggesting that when a security decision is necessary for
> a file, all the contexts it is labeled with are provided by the
> filesystem, and the security server makes a decision based on 
> whether an access path (not sure of terminology here) exists
> between the subject context and any object context.

If we followed that approach, then we wouldn't be able to tell whether
information can flow from type A to type B without analyzing the
filesystem state to see what files had multiple contexts and collapsing
each such combination into a single security equivalence class (type).

> Your httpd policy describes what contexts httpd has access to.
> Your samba policy describes what contexts smbd has access to.
> This information is not stored in the filesystem somewhere - it's 
> in the binary policy. Multiple contexts will simply allow
> the user to more accurately specify the class of the object 
> that you have to work with, with minimal interaction - it 
> is fundamentally not a samba share, or httpd content, it is both,
> and it seems the only sane thing to do is label it with both,
> or something that's a mix of the two.

You can then no longer tell whether httpd and smbd (or anything that
uses them) might interact without looking at the file attributes on
disk, as a file might have both contexts.

>  I am interested in 
> the easiest possible way to do this without playing with the policy.
> Why should I be changing the policy?

Because by allowing access by multiple domains to a single object, you
_are_ changing the policy, regardless of it is hidden or not.

>  I should
> only need to do that when I want to describe changes in 
> security classes and relationships between them. 

Allowing multiple domains that could not previously interact to do so is
changing the relationship between the security classes.

> What I want to do 
> is simply mark data as belong to more than one existing class,
> without changing either one.

That is a communication channel betweeh them.

> So, it seems to me that userspace tools should provide
> an easy way to mark a file for contexts it belongs to,
> and internally selinux could still map this information
> to a unique sid somehow. Is this possible?
> 
> I can imagine multiple contexts for processes would be useful
> as well, although I can't come up with examples right now...

Not desirable.

-- 
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 16:40, Stephen Bennett wrote:
> With only one type per file, it's possible to look at the policy and be
> certain (for example) that domain1 can't affect domain2 in any way,
> because there are no interactions allowed between the two, and the file
> types they can access don't overlap. If you allow multiple contexts per
> file, that ability goes out of the window, and you have to look at which
> files have multiple contexts and what contexts they are before you can
> figure out where information can and can't flow.
> 
> Of course I may be off here, and I may have missed more subtleties, but
> that's the problem I can see with multiple types per file. Someone
> correct me if I'm wrong here. :)

Thanks, another voice of reason...

-- 
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Wed, Jan 12, 2005 at 04:27:16PM -0500, Stephen Smalley wrote:
> On Wed, 2005-01-12 at 13:29, Luke Kenneth Casson Leighton wrote:
> >  i don't believe it does - or i am misunderstanding.
> > 
> >  having two policy files apache.fc and mymodifiedthing.fc which _both_
> >  have a file context for the same file / directory, such that the
> >  data that ends up in the security.selinux xattr is "apache_filetype_t,
> >  "mymodifiedthing_filetype_t" doesn't mean, in my book "policy is in
> >  filesystem state".
> > 
> >  ... does it?
> > 
> >  *lost*.
> 
> The file_contexts configuration is not part of the kernel policy.  It is
> only used by userspace to set the contexts for files upon installation,
> to recheck the state of the filesystem against the initial labeling
> state, or to restore portions of the filesystem to the initial labeling
> state.
> 
> If you change the SELinux module to support a list of file contexts
> within the security.selinux attribute, and change its policy engine to
> allow access if any access is allowed to any one of those contexts, then
> the only way to truly identify what information flow is possible in the
> system is by checking the current security.selinux attributes of all
> files in the system for such combinations and collapsing them to a
> single security equivalence class for analysis purposes.  

 ah, yuk.

 ... so, ultimately, it would be better to have some m4-macro-based
 tools that do that, munging to an intermediate step (which is same
 as what we have now) and then munging _that_ to a binary policy
 file (exactly as is now).

 l.
 


--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Wed, Jan 12, 2005 at 04:27:16PM -0500, Stephen Smalley wrote:

> single security equivalence class for analysis purposes.  Think:  policy
> says allow P1 F1:file read; allow P2 F2:file write;, policy analysis
> says that there is no allowed information flow from P2 to P1, but
> someone does a chcon -t F1,F2 foobar and now P2 can write to foobar and
> P1 can read from it, so information flow is now possible. 

 yep - and the policy analysis tools would need to understand the
 new format.

 1) if someone does a "chcon -t F2 foobar" all bets would be off as
    far as static analysis is concerned.

 2 ) even if they did chcon -t "F1,F2" foobar, you would still expect
     them to be doing that as an "interim" measure whilst they were
     testing something _pending_ formal analysis by putting that
     into the policy files.

 ... and once they did that, i would rationally expect the
 analysis tools to be able to cope, to "combine" 
 allow P1 F1:file read; allow P2 F2:file write; into some sort of
 pseudo-thing ... mmm... mmm...

 *thinks*...

 the analysis would need the macro-munging approach _anyway_ in
 order to "grok" the new syntax - an intermediate preprocessing
 stage that "notices" multiple-file-applications (including
 possibly expanding regexps!)  and ending up with something
 like this:

 filetype Files_with_F1_and_F2_applied_t;

 allow P1 F1:file read;
 allow P1 Files_with_F1_and_F2_applied_t:file read;
 allow P2 F2:file write;
 allow P2 Files_with_F1_and_F2_applied_t:file write;

 it'd be yeurk - but doable, i think.

 l.
 

--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Wed, Jan 12, 2005 at 09:40:46PM +0000, Stephen Bennett wrote:
> On Wed, 2005-01-12 at 13:11 -0700, Ivan Gyurdiev wrote:
> > > Because then policy would be encoded in the file attributes, not in a
> > > centralized security policy.  Hence, one would be unable to analyze
> > > information flow in the system based solely on the policy and would have
> > > to also analyze the complete filesystem state, and that state is much
> > > more subject to change at runtime than the policy itself (one would
> > > hope).
> > 
> > Please explain this some more - Luke also seems confused about this
> > (unless I misunderstand). I don't understand how the change from one
> > context to multiple contexts stored per file translates into policy
> > being encoded in the file attributes.
> 
> AIUI, the issue is something like this: 
> 
> With only one type per file, it's possible to look at the policy and be
> certain (for example) that domain1 can't affect domain2 in any way,
> because there are no interactions allowed between the two, and the file
> types they can access don't overlap. If you allow multiple contexts per
> file, that ability goes out of the window, and you have to look at which
> files have multiple contexts and what contexts they are before you can
> figure out where information can and can't flow.
 
 and you'd need to take all of the files matched by a regexp for one
 filetype, and all of the files of the other, work out if there are any
 common ones, and those would be your "multiple contexted" files.

 this you could do at policy compilation time.

 the thing is - which is easier: to expect people to do that
 analysis themselves [by modifying the default policies]
 or to do it in an automated at-pol-compile-time?
 
 what is gained and is it worth it in terms of the cost of development
 and extra complexity of the policy macroing system and the useability?

 is the extra syntax useful or hazardously complex?

 l.



--
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: Multiple contexts

[Ivan Gyurdiev]

On Wed, 2005-01-12 at 16:47 -0500, Stephen Smalley wrote:
> On Wed, 2005-01-12 at 15:11, Ivan Gyurdiev wrote:
> > Please explain this some more - Luke also seems confused about this
> > (unless I misunderstand). I don't understand how the change from one
> > context to multiple contexts stored per file translates into policy
> > being encoded in the file attributes.
> > 
> > It seems to me that this change would simply allow more accurate
> > association of the files with the proper security data.
> > 
> > It is still a centralized policy which decides whether to allow an
> > action or not - it just takes into consideration multiple contexts.
> > I am merely suggesting that when a security decision is necessary for
> > a file, all the contexts it is labeled with are provided by the
> > filesystem, and the security server makes a decision based on 
> > whether an access path (not sure of terminology here) exists
> > between the subject context and any object context.
> 
> If we followed that approach, then we wouldn't be able to tell whether
> information can flow from type A to type B without analyzing the
> filesystem state to see what files had multiple contexts and collapsing
> each such combination into a single security equivalence class (type).

What about a tool that creates a hybrid type on demand, and stores that
information in the policy?

createcon samba_httpd_content_t --inherit 
	samba_share_t httpd_sys_content_t
chcon -R samba_httpd_content_t ~/webserver

There has to be an easier way to do this than changing the original
policy file. The original policy file is hard to understand, and should
be left alone.

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Wed, Jan 12, 2005 at 04:47:41PM -0500, Stephen Smalley wrote:
> On Wed, 2005-01-12 at 15:11, Ivan Gyurdiev wrote:
> > Please explain this some more - Luke also seems confused about this
> > (unless I misunderstand). I don't understand how the change from one
> > context to multiple contexts stored per file translates into policy
> > being encoded in the file attributes.
> > 
> > It seems to me that this change would simply allow more accurate
> > association of the files with the proper security data.
> > 
> > It is still a centralized policy which decides whether to allow an
> > action or not - it just takes into consideration multiple contexts.
> > I am merely suggesting that when a security decision is necessary for
> > a file, all the contexts it is labeled with are provided by the
> > filesystem, and the security server makes a decision based on 
> > whether an access path (not sure of terminology here) exists
> > between the subject context and any object context.
> 
> If we followed that approach, then we wouldn't be able to tell whether
> information can flow from type A to type B without analyzing the
> filesystem state to see what files had multiple contexts and collapsing
> each such combination into a single security equivalence class (type).
 
 would you accept that that could be done at policy compile time,
 and that it would be unnecessary to do that at runtime?

 [if yes, then the question becomes a) who's gonna do the work
  b) is it useable without making selinux horribly complex]

 would you also agree that if someone wants to mess things up
 with chcon then all bets are off for _any_ kind of analysis?

 btw so you aren't thinking of doing something irrational in order
 to stay sane i should point out that i'm not pursuing this to be
 bloody-minded - hopefully you know me better than that by now!

 l.


--
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: Multiple contexts

[James Carter]

On Wed, 2005-01-12 at 18:32, Luke Kenneth Casson Leighton wrote:

>  would you also agree that if someone wants to mess things up
>  with chcon then all bets are off for _any_ kind of analysis?
> 

Not true.  Look at Steve's earlier example again.
allow P1 F1:file read; 
allow P2 F2:file write;

In analyzing the policy, we don't care what files are labeled with F1 or
F2, what we care about is that there is no information flow between P1
and P2.  Using chcon will not change the fact that there is no
information flow between P1 and P2.

Now imagine that we do allow lists of file contexts.  We could then go
to the extreme of having a separate type for each permission and build
the policy by using lists of contexts.
allow P P_FR:file read;
allow P P_FW:file write;
allow P P_FE:file execute;
allow Q Q_FR:file read;
allow Q Q_FW:file write;
allow Q Q_FE:file execute;
and so on.
Now label the filesystem
file1 P_FR
file2 P_FR,P_FE,Q_FR,Q_FE
file3 P_FR,P_FW,P_FE,Q_FR
and so on.

How do you analyze the system now?  What can we say about the
information flow between P and Q without looking at the filesystem?  Do
you see that the policy is now on the filesystem?  Analysis of the
policy statically will not tell you anything, you have to know how the
filesystem is labeled to have any idea of the information flows.

-- 
James Carter <jwcart2@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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 17:41, Luke Kenneth Casson Leighton wrote:
>  ... so, ultimately, it would be better to have some m4-macro-based
>  tools that do that, munging to an intermediate step (which is same
>  as what we have now) and then munging _that_ to a binary policy
>  file (exactly as is now).

I don't especially care whether it is based on m4 macros, post-processed
policy.conf, or even direct manipulation of the binary policy by a
tool.  I just don't want it in the filesystem state, which requires
complete traversal of all objects to assess.  Note that we have an
increasing ability to directly act on binary policies.  apol already
supports analysis of binary policies directly.  libsepol supports direct
manipulation of binary policies, and is already used for boolean
manipulation by several tools and for user manipulation by genpolusers. 
The experimental binary policy module work by Tresys is another good
step in this direction (but needs more people testing and experimenting
with it if it is ever going to get mainstreamed...).

-- 
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 18:01, Luke Kenneth Casson Leighton wrote:
>  yep - and the policy analysis tools would need to understand the
>  new format.

It isn't a format issue; it is whether the policy is self-contained
within the binary policy or whether it is distributed throughout the
filesystem (and more generally, the set of all object attributes).

>  1) if someone does a "chcon -t F2 foobar" all bets would be off as
>     far as static analysis is concerned.

Non-tranquility (ability to change the label on a subject or object) is
an issue, but you can bound it statically in the policy, i.e. the policy
can already ensure that F1 can never be relabeled to F2 or vice versa. 
If the policy allows F1 to be relabeled to F2 or vice versa, then that
fact will also show up in an information flow analysis of the policy,
without requiring examination of filesystem state.  Also, some further
controls over relabeling are coming in the MLS work.

>  2 ) even if they did chcon -t "F1,F2" foobar, you would still expect
>      them to be doing that as an "interim" measure whilst they were
>      testing something _pending_ formal analysis by putting that
>      into the policy files.

If the mechanism allows it to happen at all, you can't make any
guarantees without examination of the filesystem state. 

>  the analysis would need the macro-munging approach _anyway_ in
>  order to "grok" the new syntax - an intermediate preprocessing
>  stage that "notices" multiple-file-applications (including
>  possibly expanding regexps!)  and ending up with something
>  like this:

No.  The analysis tools operate on policy.conf or binary policy already;
they don't care about the macros, nor should they.  The raw policy.conf
or binary policy tells the true story about possible information flow,
and that is what we want to know.

-- 
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 18:07, Luke Kenneth Casson Leighton wrote:
>  and you'd need to take all of the files matched by a regexp for one
>  filetype, and all of the files of the other, work out if there are any
>  common ones, and those would be your "multiple contexted" files.
> 
>  this you could do at policy compilation time.

No.  As I said, file_contexts is not part of the kernel policy.  It is
only used by userspace tools like setfiles and restorecon to set the
extended attributes upon installation to an initial labeling state (or
to recheck or to restore against that initial labeling state).  If the
policy is self-contained (as it is currently), then you don't need to
look at file_contexts or the on-disk attributes in order to determine
potential information flow, although you may choose to look at them
after an analysis of the policy in order to see how "real" certain flows
might be with the current system state.

>  the thing is - which is easier: to expect people to do that
>  analysis themselves [by modifying the default policies]
>  or to do it in an automated at-pol-compile-time?

The question doesn't make sense, because the automated
at-pol-compile-time analysis cannot be done if the policy is encoded in
the filesystem.

-- 
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 18:08, Ivan Gyurdiev wrote:
> What about a tool that creates a hybrid type on demand, and stores that
> information in the policy?
> 
> createcon samba_httpd_content_t --inherit 
> 	samba_share_t httpd_sys_content_t
> chcon -R samba_httpd_content_t ~/webserver

That would certainly be feasible.  libsepol provides an interface for
direct manipulation of binary policies, so you can build tools on it
that directly perform any kind of transformation, and it is already used
for boolean customization (init, load_policy) and regenerating the user
database (genpolusers) without requiring full policy sources.  The
experimental binary policy modules work by Tresys is another step in
this direction, you might want to experiment with it (which would also
help it to mature and get it mainstreamed sooner).

However, something to note is that if tools begin to directly manage the
TE portion of the binary policy (vs. easily separable elements like
booleans and users where we can maintain local config files that
override the base settings in the shipped binary policy), then we have
to have some way to deal with merging/conflicts when policy updates
occur from a source rebuild.

-- 
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 18:32, Luke Kenneth Casson Leighton wrote:
>  would you accept that that could be done at policy compile time,
>  and that it would be unnecessary to do that at runtime?

No, it cannot be done at policy compile time, because the information
(the combinations of types on files) is not captured in the policy. 
file_contexts is not authoritative and is not part of the policy, and
the only authoritative source of information about the file attributes
is the on-disk version.  Full filesystem traversal required to do the
analysis you propose.  No examination of file_contexts or filesystem
state required to do current analysis of potential information flow
throughout the system.

>  would you also agree that if someone wants to mess things up
>  with chcon then all bets are off for _any_ kind of analysis?

Relabeling is controlled by policy already, and finer-grained control of
it is coming as part of the MLS work, so policy can bound such
relabeling to avoid illegal information flow, or at least limit the
ability to relabel in ways that violate information flow goals to
specific trusted subjects.

-- 
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: Multiple contexts

[Stephen Smalley]

On Thu, 2005-01-13 at 11:48, Luke Kenneth Casson Leighton wrote:
>   i believed that it would be acceptable to have as part of the
>   intermediate stage a full filesystem traversal, but as i mentioned
>   in the reply to james, i woke up with an insight into a flaw of
>   what i am advocating and cannot now remember what it is!

Having to analyze the complete filesystem state:
1) doesn't scale.  Think of a site with millions of files.
2) isn't stable.  Think of runtime changes occuring all the time as
files are created, destroyed, relabeled, etc.

In any event, I consider the topic (of multiple contexts per object)
closed.

-- 
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: Multiple contexts

[Stephen Smalley]

On Wed, 2005-01-12 at 18:01, Luke Kenneth Casson Leighton wrote:
>  2 ) even if they did chcon -t "F1,F2" foobar, you would still expect
>      them to be doing that as an "interim" measure whilst they were
>      testing something _pending_ formal analysis by putting that
>      into the policy files.

BTW, idle question:  how do you decide whether to allow setting such
combinations on a file?  What happens if a file already has a
combination - how do you decide whether or not you can change those
settings?  Simply allowing it if you can relabel any one of the types is
obviously broken...

-- 
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Thu, Jan 13, 2005 at 08:56:41AM -0500, James Carter wrote:
> On Wed, 2005-01-12 at 18:32, Luke Kenneth Casson Leighton wrote:
> 
> >  would you also agree that if someone wants to mess things up
> >  with chcon then all bets are off for _any_ kind of analysis?

 sorry i meant to qualify: any kind of analysis using just the
 policy files alone.

> > 
> 
> Not true.  Look at Steve's earlier example again.


 at some time when i woke up this morning, i had a flash of inspiration.

 i recognised that there was a problem with what i was proposing.

 it was something to do with creating new files, that not even
 an "intermediate" policy based off of combining and creating
 "intermediate" filetypes would fix, without, as you say,
 examining all files covered by an "intermediate" regexp.

 i could not, for the life of me, tell you what that is, now.

 ... something to do with working out what the overlaps between
 two regexps for file contexts, creating new regexps in a venn
 diagram like fashion, then applying them with setfiles...

 ... and yet that still doesn't help.

 so, yes.

 time to drop it :)

 l.


--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Thu, Jan 13, 2005 at 11:16:06AM -0500, Stephen Smalley wrote:
> On Wed, 2005-01-12 at 18:32, Luke Kenneth Casson Leighton wrote:
> >  would you accept that that could be done at policy compile time,
> >  and that it would be unnecessary to do that at runtime?
> 
> No, it cannot be done at policy compile time, because the information
> (the combinations of types on files) is not captured in the policy. 
> file_contexts is not authoritative and is not part of the policy, and
> the only authoritative source of information about the file attributes
> is the on-disk version.  Full filesystem traversal required to do the
> analysis you propose.  No examination of file_contexts or filesystem
> state required to do current analysis of potential information flow
> throughout the system.
 
  i believed that it would be acceptable to have as part of the
  intermediate stage a full filesystem traversal, but as i mentioned
  in the reply to james, i woke up with an insight into a flaw of
  what i am advocating and cannot now remember what it is!
  
  sorry!

  l.,

--
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: Multiple contexts

[Stephen Smalley]

On Thu, 2005-01-13 at 12:17, Luke Kenneth Casson Leighton wrote:
>  and there would therefore be in the policy.conf file lots of things
>  like "allow F1,F2 such-and-such".

Regardless of how the logic is implemented/specified, you had originally
proposed allowing access if access to any one of the types was allowed. 
But in the case of relabeling a file with multiple types, that logic
seems flawed, e.g. I doubt you want to allow someone to relabel a file
from F1,F2 to only F1 just because they have permission to
relabelfrom/to F1 but lack permission to relabel F2.

>  i thought that the only tricky bit would be at policy compile-time to
>  have to run through the complete list of files on the filesystem (which
>  is done by setfiles _anyway) making a distinction between the overlap
>  of the regexp associated with F1 and the regexp associated with F2.

No, you misunderstand.  setfiles is not run at policy compilation time. 
setfiles is only run at system install time (and in fact, it isn't even
run then anymore, as rpm now handles labeling upon install for us now).

-- 
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: Multiple contexts

[Stephen Smalley]

On Thu, 2005-01-13 at 12:19, Luke Kenneth Casson Leighton wrote:
> > Having to analyze the complete filesystem state:
> > 1) doesn't scale.  Think of a site with millions of files.
> 
>  ... setfiles?

As I've said repeatedly, setfiles was only intended to be used to
perform initial labeling upon installation, and possibly to periodically
recheck/restore portions of the filesystem against the initial labeling
state.  Nothing else.

-- 
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Thu, Jan 13, 2005 at 11:44:31AM -0500, Stephen Smalley wrote:
> On Wed, 2005-01-12 at 18:01, Luke Kenneth Casson Leighton wrote:
> >  2 ) even if they did chcon -t "F1,F2" foobar, you would still expect
> >      them to be doing that as an "interim" measure whilst they were
> >      testing something _pending_ formal analysis by putting that
> >      into the policy files.
> 
> BTW, idle question:  how do you decide whether to allow setting such
> combinations on a file?  

 i thought that it would be because the "intermediate" stage would have
 generated a filetype called "F1,F2" which may actually only require
 some extensions etc. to simply add "," as an allowed character in the
 file types and the policy compiler.

 and there would therefore be in the policy.conf file lots of things
 like "allow F1,F2 such-and-such".

 i thought that the only tricky bit would be at policy compile-time to
 have to run through the complete list of files on the filesystem (which
 is done by setfiles _anyway) making a distinction between the overlap
 of the regexp associated with F1 and the regexp associated with F2.

 l.


--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Thu, Jan 13, 2005 at 11:37:18AM -0500, Stephen Smalley wrote:
> On Thu, 2005-01-13 at 11:48, Luke Kenneth Casson Leighton wrote:
> >   i believed that it would be acceptable to have as part of the
> >   intermediate stage a full filesystem traversal, but as i mentioned
> >   in the reply to james, i woke up with an insight into a flaw of
> >   what i am advocating and cannot now remember what it is!
> 
> Having to analyze the complete filesystem state:
> 1) doesn't scale.  Think of a site with millions of files.

 ... setfiles?

> 2) isn't stable.  Think of runtime changes occuring all the time as
> files are created, destroyed, relabeled, etc.
> 
> In any event, I consider the topic (of multiple contexts per object)
> closed.
 
 ack.  likewise.  wish i could remember what the flaw was.



--
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: Multiple contexts

[Luke Kenneth Casson Leighton]

On Thu, Jan 13, 2005 at 11:10:19AM -0500, Stephen Smalley wrote:
> On Wed, 2005-01-12 at 18:08, Ivan Gyurdiev wrote:
> > What about a tool that creates a hybrid type on demand, and stores that
> > information in the policy?

 i believe that the same issues apply to the "hybrid" types
 as apply to "ACLs" - the only difference that i perceive is
 the letters contained in the file_contexts [whether a ","
 is allowed in the name of the "hybrid" type].

 the only complication therefore would be that if your users expected
 to create a combination - a "hybrid" type not previously encountered
 before: that's doable though.

 l.
 


--
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: Multiple contexts

[Thomas Bleher]

[-- Attachment #1.1: Type: text/plain, Size: 1099 bytes --]

* Ivan Gyurdiev <ivg2@cornell.edu> [2005-01-13 01:14]:
> What about a tool that creates a hybrid type on demand, and stores that
> information in the policy?
> 
> createcon samba_httpd_content_t --inherit 
> 	samba_share_t httpd_sys_content_t
> chcon -R samba_httpd_content_t ~/webserver

This seems very useful. I have experimented a bit with this idea this
evening; the resulting script is attached. It takes a policy.conf and
outputs a new type (plus corresponding rules).
The script is not perfect because it parses the policy.conf itself, but
it should work for almost all file_types.

You will still need policy sources, but you won't need to go through
all sources to find the appropriate rules, the following should do the
trick (not tested):

# cd /etc/selinux/strict/src/policy
# make policy.conf
# createcon samba_httpd_content_t samba_share_t httpd_sys_content_t < policy.conf >> domains/misc/local.te
# make reload

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

[-- Attachment #1.2: createcon --]
[-- Type: text/plain, Size: 3508 bytes --]

#!/usr/bin/perl -w
#
# this script creates a new SELinux type which is the union of two types
# (C) 2005 by Thomas Bleher under the GNU GPL
#
# Please note that this is just proof of concept code; it has some limitations:
# * assumes every statement is one line
# * does not really handle "{ domain - foo_t }"
# * does not always handle ~ correctly; this shouldn't be a problem with current policy
# * does not handle type_change and type_transition (not sure if there even is a correct way)
# * only works on file_type (domains would need role type statements and are more difficult 
#   because of domain_auto_trans())
# * neverallow and constraints are not properly handled
# * might generate duplicate permissions (these are not harmful)
#
# despite this, it should work most of the time

if (@ARGV < 3) {
	print STDERR "Usage: createcon [NewType] [OldType1] [OldType2]\n";
	print STDERR "policy info (policy.conf) is read from standard in\n";
	print STDERR "Example: createcon samba_httpd_content_t samba_share_t httpd_sys_content_t < policy.conf\n";
	exit(1);
}

# get command line arguments
my ($new_type, $type1, $type2) = splice(@ARGV, 0, 3);


# parse the policy

$pat = '(\w+|~?{[^}]+}|\*)\s*'; # $pat matches on foo_t or { foo_t bar_t } or *

while (<>) {
	# remove everything we do not need
	s/#.*?$//mg; # comments
	s/^\s*$//mg; # empty lines
	next if /^[\s\n]*$/;

	# remove duplicate braces (we have to loop until all are gone)
	# this is for things like "{ read{getattr {write setattr }}}"
	for ( ;s/{([^}]*){([^}]*)}/{$1 $2/g; ) {}

	if (/if \s* \( ([^\)]+) \)/x) { # save all active bools in a stack
		push @bools, $1;

	} elsif (/(allow|dontaudit|auditallow|auditdeny) \s+ $pat \s+ $pat : \s* $pat \s+ $pat;/x) { # normal rules
		my $bool = join ') && (', @bools;
		push @{$rules{$1}}, [$2,$3,$4,$5,$bool];

	} elsif (/type\s+([^;]+);/) {
		my @tmp = split /,\s+/, $1; # get attributes
		my $type = shift @tmp;
		$types{$type} = [@tmp];

	} elsif (/typeattribute\s+(\w+)\s+(\w+)/) {
		push @{$types{$1}}, $2;

	} elsif (/\}/) { # this rule has to be the last so we don't grab braces from an allow rule
		pop @bools;
	}
}

# create a new type which is the union of the old types
my (%tmp);
for (@{$types{$type1}}) {
	$tmp{$_}++;
}
for (@{$types{$type2}}) {
	$tmp{$_}++;
}
print "type $new_type, ", join(", ", keys %tmp), ";\n";


# now create the rules

for $ruletype (keys %rules) {
	for (@{$rules{$ruletype}}) { # traverse all the rules

		if ($_->[0] =~ /$type1|$type2/) { # not sure if this is correct; what happens if a type is twice in a rule?
			$_->[0] = $new_type; # replace source

		} elsif ($_->[1] =~ /$type1|$type2/) {
			$_->[1] = $new_type; # replace target

		} else { # ignore all other rules
			next;
		}

		# now print it
		if ($_->[4] ne '') { # any bools active?
			print "if ($_->[4]) {\n";
			print "$ruletype $_->[0] $_->[1]:$_->[2] $_->[3];\n";
			print "}\n";
		} else {
			print "$ruletype $_->[0] $_->[1]:$_->[2] $_->[3];\n";
		}
	}
}

__END__

# not used currently, but nice for debugging:

# print all the stuff we have extracted
for (keys %types) {
	print "type $_, ", join(", ", @{$types{$_}}), ";\n";
}
for $ruletype (keys %rules) {
	for (@{$rules{$ruletype}}) {
		if ($_->[4] ne '') {
			print "if ($_->[4]) {\n$ruletype $_->[0] $_->[1]:$_->[2] $_->[3];\n}\n";
		} else {
			print "$ruletype $_->[0] $_->[1]:$_->[2] $_->[3];\n";
		}
	}
}

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

Re: Multiple contexts

[Ivan Gyurdiev]

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


> This seems very useful. I have experimented a bit with this idea this
> evening; the resulting script is attached. It takes a policy.conf and
> outputs a new type (plus corresponding rules).
> The script is not perfect because it parses the policy.conf itself, but
> it should work for almost all file_types.

Modified to work for N>=2 parent types, and fixes a bug in regexp to
match exact type, not any string containing it.

Disclaimer: I don't know a thing about perl.

... However, yes, I think it would be useful to have some sort of script
to do this kind of thing as part of the selinux tools. I shouldn't have
to tell it where to read from and write to.




-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University

[-- Attachment #2: createcon --]
[-- Type: application/x-perl, Size: 3470 bytes --]

Re: Multiple contexts

[Ivan Gyurdiev]

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

On Fri, 2005-01-14 at 00:07 -0700, Ivan Gyurdiev wrote:
> > This seems very useful. I have experimented a bit with this idea this
> > evening; the resulting script is attached. It takes a policy.conf and
> > outputs a new type (plus corresponding rules).
> > The script is not perfect because it parses the policy.conf itself, but
> > it should work for almost all file_types.
> 
> Modified to work for N>=2 parent types, and fixes a bug in regexp to
> match exact type, not any string containing it.
> 
> Disclaimer: I don't know a thing about perl.
> 
> ... However, yes, I think it would be useful to have some sort of script
> to do this kind of thing as part of the selinux tools. I shouldn't have
> to tell it where to read from and write to.

Corrected regexps. New version attached.


-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University

[-- Attachment #2: createcon --]
[-- Type: application/x-perl, Size: 3502 bytes --]