[RFC PATCH 1/3] reference policy: add "context" security class

[RFC PATCH 1/3] reference policy: add "context" security class

[Darrel Goeddel]

Define a new security class "context" and its permission "translate" for
use by the context translation daemon.  The bit of policy added to the
setrans_translate_context interface only allows for translation of
domains and file_contexts.  You can see how this is bad if you try to
ls -Z /dev.  I don't have a trick to allow TE access to every type other
than grabbing some "big" attributes, then listing every remaining type.
That obviously does not work in the modular policy model anyway.  Any
ideas on how we could maybe handle that one? (assuming that anyone else
does not want TE restriction on the translations :))  How about a
privilege to use '*' or '~' in typesets...


---


diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
index 5d4f36a..1ef6041 100644
--- a/policy/flask/access_vectors
+++ b/policy/flask/access_vectors
@@ -632,3 +632,8 @@ class key
 	setattr
 	create
 }
+
+class context
+{
+	translate
+}
diff --git a/policy/flask/security_classes b/policy/flask/security_classes
index 57f49bc..53c0cf1 100644
--- a/policy/flask/security_classes
+++ b/policy/flask/security_classes
@@ -93,4 +93,6 @@ class packet
 # Kernel access key retention
 class key
 
+class context			# userspace
+
 # FLASK
diff --git a/policy/mls b/policy/mls
index 06085c5..325a2a5 100644
--- a/policy/mls
+++ b/policy/mls
@@ -617,4 +617,14 @@ mlsconstrain association { polmatch }
 	((( l1 dom l2 ) and ( h1 domby h2 )) or
 	 ( t2 == unlabeled_t ));
 
+
+
+
+#
+# MLS policy for the context class
+#
+
+mlsconstrain context translate
+	( h1 dom h2 );
+
 ') dnl end enable_mls
diff --git a/policy/modules/system/setrans.if b/policy/modules/system/setrans.if
index 9547503..d230770 100644
--- a/policy/modules/system/setrans.if
+++ b/policy/modules/system/setrans.if
@@ -22,4 +22,5 @@ interface(`setrans_translate_context',`
 	allow $1 setrans_var_run_t:sock_file rw_file_perms;
 	allow $1 setrans_var_run_t:dir search_dir_perms;
 	files_list_pids($1)
+	allow $1 { domain file_type }:context translate;
 ')

--
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: [RFC PATCH 1/3] reference policy: add "context" security class

[Joshua Brindle]

Darrel Goeddel wrote:
> Define a new security class "context" and its permission "translate" for
> use by the context translation daemon.  The bit of policy added to the
> setrans_translate_context interface only allows for translation of
> domains and file_contexts.  You can see how this is bad if you try to
> ls -Z /dev.  I don't have a trick to allow TE access to every type other
> than grabbing some "big" attributes, then listing every remaining type.
> That obviously does not work in the modular policy model anyway.  Any
> ideas on how we could maybe handle that one? (assuming that anyone else
> does not want TE restriction on the translations :))  How about a
> privilege to use '*' or '~' in typesets...
>
* and ~ in typesets considered harmful. In addition to the badness of 
not actually knowing what you are giving access to they would cause the 
avtab to be much bigger (they'd have to be expanded whereas "big" 
attributes don't anymore).

However, I'm not sure you want to go this route anyway. You are 
basically implying that the label of a context is the context itself 
(mind bending I know, we did this same thing forever ago with the policy 
server). We finally decided that it was much better to explicitly label 
then (this was part of the '.' notation). For example the policy server 
labeling file might have:

type apache_t   system_u:object_r:apache_root_type_t
type apache_t.   system_u:object_r:apache_types_t

then you can give access to everything "under" apache_t in the hierarchy 
with just one allow rule but not give access to apache_t. I know this 
exact thing won't work for you since you are doing full contexts but you 
may want to consider your labeling scheme.

In the mean time, since the translation permissions is primarily for MLS 
anyway you might consider a much more course permission that lets you do 
translations in general with the expectation that at some point in the 
future you could implement a more fine grained mechanism.

--
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: [RFC PATCH 1/3] reference policy: add "context" security class

[Darrel Goeddel]

Joshua Brindle wrote:
> Darrel Goeddel wrote:
> 
>> Define a new security class "context" and its permission "translate" for
>> use by the context translation daemon.  The bit of policy added to the
>> setrans_translate_context interface only allows for translation of
>> domains and file_contexts.  You can see how this is bad if you try to
>> ls -Z /dev.  I don't have a trick to allow TE access to every type other
>> than grabbing some "big" attributes, then listing every remaining type.
>> That obviously does not work in the modular policy model anyway.  Any
>> ideas on how we could maybe handle that one? (assuming that anyone else
>> does not want TE restriction on the translations :))  How about a
>> privilege to use '*' or '~' in typesets...
>>
> * and ~ in typesets considered harmful. In addition to the badness of 
> not actually knowing what you are giving access to they would cause the 
> avtab to be much bigger (they'd have to be expanded whereas "big" 
> attributes don't anymore).

I know, I agreed with the restriction.  I just didn't have a situation
back then where I only wanted an MLS check :(

> However, I'm not sure you want to go this route anyway. You are 
> basically implying that the label of a context is the context itself 
> (mind bending I know, we did this same thing forever ago with the policy 
> server). We finally decided that it was much better to explicitly label 
> then (this was part of the '.' notation). For example the policy server 
> labeling file might have:
> 
> type apache_t   system_u:object_r:apache_root_type_t
> type apache_t.   system_u:object_r:apache_types_t
> 
> then you can give access to everything "under" apache_t in the hierarchy 
> with just one allow rule but not give access to apache_t. I know this 
> exact thing won't work for you since you are doing full contexts but you 
> may want to consider your labeling scheme.

We could make a "shadow" to every type on the system like foo_t would have
foo_t.context_type_t, then give all of the *.context_type_t types an attribute
of context_type, and then do "allow domain context_type:context translate;".
Anyone mind if I double the number of types?  I'm note really serious here
in case anyone was wondering ;)

> In the mean time, since the translation permissions is primarily for MLS 
> anyway you might consider a much more course permission that lets you do 
> translations in general with the expectation that at some point in the 
> future you could implement a more fine grained mechanism.

I take it that you are talking about something like a "self" permission
(allow domain self:security translate_context; or some such).  The problem there
is that the actual context must be the target of the check so we can actually
do the MLS comparison.  If I misunderstood, could you please explain further.

-- 

Darrel

--
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: [RFC PATCH 1/3] reference policy: add "context" security class

[Stephen Smalley]

On Thu, 2006-10-05 at 14:20 -0500, Darrel Goeddel wrote:
> Joshua Brindle wrote:
> > Darrel Goeddel wrote:
> > 
> >> Define a new security class "context" and its permission "translate" for
> >> use by the context translation daemon.  The bit of policy added to the
> >> setrans_translate_context interface only allows for translation of
> >> domains and file_contexts.  You can see how this is bad if you try to
> >> ls -Z /dev.  I don't have a trick to allow TE access to every type other
> >> than grabbing some "big" attributes, then listing every remaining type.
> >> That obviously does not work in the modular policy model anyway.  Any
> >> ideas on how we could maybe handle that one? (assuming that anyone else
> >> does not want TE restriction on the translations :))  How about a
> >> privilege to use '*' or '~' in typesets...
> >>
> > * and ~ in typesets considered harmful. In addition to the badness of 
> > not actually knowing what you are giving access to they would cause the 
> > avtab to be much bigger (they'd have to be expanded whereas "big" 
> > attributes don't anymore).
> 
> I know, I agreed with the restriction.  I just didn't have a situation
> back then where I only wanted an MLS check :(
> 
> > However, I'm not sure you want to go this route anyway. You are 
> > basically implying that the label of a context is the context itself 
> > (mind bending I know, we did this same thing forever ago with the policy 
> > server). We finally decided that it was much better to explicitly label 
> > then (this was part of the '.' notation). For example the policy server 
> > labeling file might have:
> > 
> > type apache_t   system_u:object_r:apache_root_type_t
> > type apache_t.   system_u:object_r:apache_types_t
> > 
> > then you can give access to everything "under" apache_t in the hierarchy 
> > with just one allow rule but not give access to apache_t. I know this 
> > exact thing won't work for you since you are doing full contexts but you 
> > may want to consider your labeling scheme.
> 
> We could make a "shadow" to every type on the system like foo_t would have
> foo_t.context_type_t, then give all of the *.context_type_t types an attribute
> of context_type, and then do "allow domain context_type:context translate;".
> Anyone mind if I double the number of types?  I'm note really serious here
> in case anyone was wondering ;)
> 
> > In the mean time, since the translation permissions is primarily for MLS 
> > anyway you might consider a much more course permission that lets you do 
> > translations in general with the expectation that at some point in the 
> > future you could implement a more fine grained mechanism.
> 
> I take it that you are talking about something like a "self" permission
> (allow domain self:security translate_context; or some such).  The problem there
> is that the actual context must be the target of the check so we can actually
> do the MLS comparison.

Given that translation doesn't actually translate the TE component at
this time, making the check per-type serves no purpose.  So you could
just manipulate the target context for the purposes of checking such
that it has the actual MLS label of the target but a fixed
user:role:type prefix.  Then the TE policy is quite simple - a single
rule for all domains (allow domain translate_t:context translate;).

>   If I misunderstood, could you please explain further.

-- 
Stephen Smalley
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: [RFC PATCH 1/3] reference policy: add "context" security class

[Darrel Goeddel]

Stephen Smalley wrote:
> On Thu, 2006-10-05 at 14:20 -0500, Darrel Goeddel wrote:
> 
>>Joshua Brindle wrote:
>>
>>>Darrel Goeddel wrote:
>>>
>>>
>>>>Define a new security class "context" and its permission "translate" for
>>>>use by the context translation daemon.  The bit of policy added to the
>>>>setrans_translate_context interface only allows for translation of
>>>>domains and file_contexts.  You can see how this is bad if you try to
>>>>ls -Z /dev.  I don't have a trick to allow TE access to every type other
>>>>than grabbing some "big" attributes, then listing every remaining type.
>>>>That obviously does not work in the modular policy model anyway.  Any
>>>>ideas on how we could maybe handle that one? (assuming that anyone else
>>>>does not want TE restriction on the translations :))  How about a
>>>>privilege to use '*' or '~' in typesets...
>>>>
>>>
>>>* and ~ in typesets considered harmful. In addition to the badness of 
>>>not actually knowing what you are giving access to they would cause the 
>>>avtab to be much bigger (they'd have to be expanded whereas "big" 
>>>attributes don't anymore).
>>
>>I know, I agreed with the restriction.  I just didn't have a situation
>>back then where I only wanted an MLS check :(
>>
>>
>>>However, I'm not sure you want to go this route anyway. You are 
>>>basically implying that the label of a context is the context itself 
>>>(mind bending I know, we did this same thing forever ago with the policy 
>>>server). We finally decided that it was much better to explicitly label 
>>>then (this was part of the '.' notation). For example the policy server 
>>>labeling file might have:
>>>
>>>type apache_t   system_u:object_r:apache_root_type_t
>>>type apache_t.   system_u:object_r:apache_types_t
>>>
>>>then you can give access to everything "under" apache_t in the hierarchy 
>>>with just one allow rule but not give access to apache_t. I know this 
>>>exact thing won't work for you since you are doing full contexts but you 
>>>may want to consider your labeling scheme.
>>
>>We could make a "shadow" to every type on the system like foo_t would have
>>foo_t.context_type_t, then give all of the *.context_type_t types an attribute
>>of context_type, and then do "allow domain context_type:context translate;".
>>Anyone mind if I double the number of types?  I'm note really serious here
>>in case anyone was wondering ;)
>>
>>
>>>In the mean time, since the translation permissions is primarily for MLS 
>>>anyway you might consider a much more course permission that lets you do 
>>>translations in general with the expectation that at some point in the 
>>>future you could implement a more fine grained mechanism.
>>
>>I take it that you are talking about something like a "self" permission
>>(allow domain self:security translate_context; or some such).  The problem there
>>is that the actual context must be the target of the check so we can actually
>>do the MLS comparison.
> 
> 
> Given that translation doesn't actually translate the TE component at
> this time, making the check per-type serves no purpose.  So you could
> just manipulate the target context for the purposes of checking such
> that it has the actual MLS label of the target but a fixed
> user:role:type prefix.  Then the TE policy is quite simple - a single
> rule for all domains (allow domain translate_t:context translate;).

Wow, I actually had that idea typed in right there in my message, but I
deleted it after I considered the overhead.  Must be the NSA's email undelete
feature at work ;)  I was considering doing a check between
process vs. "system_u:system_r:dummy_translation_type_t:<mls from context>"

That would entail creating a context struct from target context, then setting
up the fake values, and then extracting the new string from that struct to
get the context to use for the avc check.  How do you think that stacks up
compared to the overhead already incurred?  I like this idea if it is
acceptable.  

-- 

Darrel

--
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: [RFC PATCH 1/3] reference policy: add "context" security class

[Joshua Brindle]

On Thu, 2006-10-05 at 14:20 -0500, Darrel Goeddel wrote:
> Joshua Brindle wrote:
> > Darrel Goeddel wrote:
> > 
> >> Define a new security class "context" and its permission "translate" for
> >> use by the context translation daemon.  The bit of policy added to the
> >> setrans_translate_context interface only allows for translation of
> >> domains and file_contexts.  You can see how this is bad if you try to
> >> ls -Z /dev.  I don't have a trick to allow TE access to every type other
> >> than grabbing some "big" attributes, then listing every remaining type.
> >> That obviously does not work in the modular policy model anyway.  Any
> >> ideas on how we could maybe handle that one? (assuming that anyone else
> >> does not want TE restriction on the translations :))  How about a
> >> privilege to use '*' or '~' in typesets...
> >>
> > * and ~ in typesets considered harmful. In addition to the badness of 
> > not actually knowing what you are giving access to they would cause the 
> > avtab to be much bigger (they'd have to be expanded whereas "big" 
> > attributes don't anymore).
> 
> I know, I agreed with the restriction.  I just didn't have a situation
> back then where I only wanted an MLS check :(
> 

well your situation now is clearly wrong :)

> > However, I'm not sure you want to go this route anyway. You are 
> > basically implying that the label of a context is the context itself 
> > (mind bending I know, we did this same thing forever ago with the policy 
> > server). We finally decided that it was much better to explicitly label 
> > then (this was part of the '.' notation). For example the policy server 
> > labeling file might have:
> > 
> > type apache_t   system_u:object_r:apache_root_type_t
> > type apache_t.   system_u:object_r:apache_types_t
> > 
> > then you can give access to everything "under" apache_t in the hierarchy 
> > with just one allow rule but not give access to apache_t. I know this 
> > exact thing won't work for you since you are doing full contexts but you 
> > may want to consider your labeling scheme.
> 
> We could make a "shadow" to every type on the system like foo_t would have
> foo_t.context_type_t, then give all of the *.context_type_t types an attribute
> of context_type, and then do "allow domain context_type:context translate;".
> Anyone mind if I double the number of types?  I'm note really serious here
> in case anyone was wondering ;)
> 

you jest but this is closer to the truth than you think. By implicitly
labeling contexts with themselves you are destroying the concept of a
type (as an equivalence class). The evidence to this is that you are
looking for a way to add rules for every type (clearly you want 1
security equivalence class for them).

> > In the mean time, since the translation permissions is primarily for MLS 
> > anyway you might consider a much more course permission that lets you do 
> > translations in general with the expectation that at some point in the 
> > future you could implement a more fine grained mechanism.
> 
> I take it that you are talking about something like a "self" permission
> (allow domain self:security translate_context; or some such).  The problem there
> is that the actual context must be the target of the check so we can actually
> do the MLS comparison.  If I misunderstood, could you please explain further.
> 

thinking about this... you are right, we don't have a way to just
compare MLS and don't really want one either. An easy solution is to
specify a default label for all types in a config file and to use that
label combined with the level of the target being translated to get an
answer. Something like:

default_context system_u:object_r:all_types_t

requester is sysadm_t:s0, target being translated is foo_t:s1, request
is (shorthanded)

avc_has_perm(::sysadm_t:s0, ::all_types_t:s1, security,
translate_context);

you'll have a TE rule allow sysadm_t (or domain) all_types_t : security
translate_context;

this is essentially poor-mans labeling but it leaves the door open for
more fine grained labeling down the road (particularly as the use of
hierarchical namespaces picks up)



--
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: [RFC PATCH 1/3] reference policy: add "context" security class

[Christopher J. PeBenito]

On Thu, 2006-10-05 at 13:05 -0500, Darrel Goeddel wrote:
> Define a new security class "context" and its permission "translate" for
> use by the context translation daemon.  The bit of policy added to the
> setrans_translate_context interface only allows for translation of
> domains and file_contexts.  You can see how this is bad if you try to
> ls -Z /dev.

Yes, as device nodes don't have the file_type attribute, they have
device_node.

> I don't have a trick to allow TE access to every type other
> than grabbing some "big" attributes, then listing every remaining type.
> That obviously does not work in the modular policy model anyway.  Any
> ideas on how we could maybe handle that one? (assuming that anyone else
> does not want TE restriction on the translations :))  How about a
> privilege to use '*' or '~' in typesets...

It shouldn't be to hard to build up, we just need things like:

files_translate_all_contexts()
corenet_translate_all_contexts()
fs_translate_all_contexts()
dev_translate_all_contexts()
domain_translate_all_contexts()

I believe that are the modules that need translate interfaces, and that
should be fairly comprehensive coverage (not complete).

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: [RFC PATCH 1/3] reference policy: add "context" security class

[Darrel Goeddel]

Christopher J. PeBenito wrote:
> On Thu, 2006-10-05 at 13:05 -0500, Darrel Goeddel wrote:
> 
>>Define a new security class "context" and its permission "translate" for
>>use by the context translation daemon.  The bit of policy added to the
>>setrans_translate_context interface only allows for translation of
>>domains and file_contexts.  You can see how this is bad if you try to
>>ls -Z /dev.
> 
> 
> Yes, as device nodes don't have the file_type attribute, they have
> device_node.
> 
> 
>>I don't have a trick to allow TE access to every type other
>>than grabbing some "big" attributes, then listing every remaining type.
>>That obviously does not work in the modular policy model anyway.  Any
>>ideas on how we could maybe handle that one? (assuming that anyone else
>>does not want TE restriction on the translations :))  How about a
>>privilege to use '*' or '~' in typesets...
> 
> 
> It shouldn't be to hard to build up, we just need things like:
> 
> files_translate_all_contexts()
> corenet_translate_all_contexts()
> fs_translate_all_contexts()
> dev_translate_all_contexts()
> domain_translate_all_contexts()

I'd prefer to keep one interface that gives TE access to translate all contexts.
We really want the translations to happen in general, just not if there is an
MLS violation.  I look at it as more of a allow by default, deny specific type
of check.  I don't see why something would want the ability to translate the MLS
portion of contexts containing "dev" types, but nothing else.  You are just limiting
yourself to the ugly representation of the MLS info.  We actually replace the MLS
portion of the context with "???" if the translation fails in our translation
daemon - rendering the context useless.  No soup for you!  Getting back on track...
It'd be nice if we could say that all types had one of { domain file_type
device_node etc. } so we could just have all of those in the allow rule for the
setrans_translate_context interface.  Any idea how many types are currently not
covered by an attribute (kind of a general classification attribute) like that?

-- 

Darrel

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