[PATCH] libselinux: add "poly_property" type to X contexts backend

[PATCH] libselinux: add "poly_property" type to X contexts backend

[Eamon Walsh]

This patch adds a poly_property type to the X contexts backend, so that 
the X Flask module can be informed which properties to polyinstantiate.

Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
---

 include/selinux/label.h |    1 +
 src/label_x.c           |    2 ++
 2 files changed, 3 insertions(+)


Index: libselinux/include/selinux/label.h
===================================================================
--- libselinux/include/selinux/label.h	(revision 2789)
+++ libselinux/include/selinux/label.h	(working copy)
@@ -113,6 +113,7 @@
 #define SELABEL_X_CLIENT	3
 #define SELABEL_X_EVENT		4
 #define SELABEL_X_SELN		5
+#define SELABEL_X_POLYPROP	6
 
 
 #ifdef __cplusplus
Index: libselinux/src/label_x.c
===================================================================
--- libselinux/src/label_x.c	(revision 2789)
+++ libselinux/src/label_x.c	(working copy)
@@ -69,6 +69,8 @@
 			data->spec_arr[data->nspec].type = SELABEL_X_EVENT;
 		else if (!strcmp(type, "selection"))
 			data->spec_arr[data->nspec].type = SELABEL_X_SELN;
+		else if (!strcmp(type, "poly_property"))
+			data->spec_arr[data->nspec].type = SELABEL_X_POLYPROP;
 		else {
 			selinux_log(SELINUX_WARNING,
 				    "%s:  line %d has invalid object type %s\n",

-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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: [PATCH] libselinux: add "poly_property" type to X contexts backend

[Xavier Toth]

I'm curious as to why you chose the route of specifying which
properties are polyinstantiated instead of which are not bearing in
mind what Glenn said in a previous post?

On Feb 5, 2008 3:30 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> This patch adds a poly_property type to the X contexts backend, so that
> the X Flask module can be informed which properties to polyinstantiate.
>
> Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
> ---
>
>  include/selinux/label.h |    1 +
>  src/label_x.c           |    2 ++
>  2 files changed, 3 insertions(+)
>
>
> Index: libselinux/include/selinux/label.h
> ===================================================================
> --- libselinux/include/selinux/label.h  (revision 2789)
> +++ libselinux/include/selinux/label.h  (working copy)
> @@ -113,6 +113,7 @@
>  #define SELABEL_X_CLIENT       3
>  #define SELABEL_X_EVENT                4
>  #define SELABEL_X_SELN         5
> +#define SELABEL_X_POLYPROP     6
>
>
>  #ifdef __cplusplus
> Index: libselinux/src/label_x.c
> ===================================================================
> --- libselinux/src/label_x.c    (revision 2789)
> +++ libselinux/src/label_x.c    (working copy)
> @@ -69,6 +69,8 @@
>                         data->spec_arr[data->nspec].type = SELABEL_X_EVENT;
>                 else if (!strcmp(type, "selection"))
>                         data->spec_arr[data->nspec].type = SELABEL_X_SELN;
> +               else if (!strcmp(type, "poly_property"))
> +                       data->spec_arr[data->nspec].type = SELABEL_X_POLYPROP;
>                 else {
>                         selinux_log(SELINUX_WARNING,
>                                     "%s:  line %d has invalid object type %s\n",
>
> --
> Eamon Walsh <ewalsh@tycho.nsa.gov>
> 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.
>

--
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: [PATCH] libselinux: add "poly_property" type to X contexts backend

[Eamon Walsh]

Xavier Toth wrote:
> I'm curious as to why you chose the route of specifying which
> properties are polyinstantiated instead of which are not bearing in
> mind what Glenn said in a previous post?
>   

The server will check the "property" lines first and if it doesn't find 
a match it will check the "poly_property" lines.  So, as long as the 
wildcard entry in the x_contexts file is changed from property to 
poly_property, the default will be to polyinstantiate.

However I wasn't planning on treating the root window any differently 
from other windows, so this behavior would apply to all windows.


> On Feb 5, 2008 3:30 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>   
>> This patch adds a poly_property type to the X contexts backend, so that
>> the X Flask module can be informed which properties to polyinstantiate.
>>
>> Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
>> ---
>>
>>  include/selinux/label.h |    1 +
>>  src/label_x.c           |    2 ++
>>  2 files changed, 3 insertions(+)
>>
>>
>> Index: libselinux/include/selinux/label.h
>> ===================================================================
>> --- libselinux/include/selinux/label.h  (revision 2789)
>> +++ libselinux/include/selinux/label.h  (working copy)
>> @@ -113,6 +113,7 @@
>>  #define SELABEL_X_CLIENT       3
>>  #define SELABEL_X_EVENT                4
>>  #define SELABEL_X_SELN         5
>> +#define SELABEL_X_POLYPROP     6
>>
>>
>>  #ifdef __cplusplus
>> Index: libselinux/src/label_x.c
>> ===================================================================
>> --- libselinux/src/label_x.c    (revision 2789)
>> +++ libselinux/src/label_x.c    (working copy)
>> @@ -69,6 +69,8 @@
>>                         data->spec_arr[data->nspec].type = SELABEL_X_EVENT;
>>                 else if (!strcmp(type, "selection"))
>>                         data->spec_arr[data->nspec].type = SELABEL_X_SELN;
>> +               else if (!strcmp(type, "poly_property"))
>> +                       data->spec_arr[data->nspec].type = SELABEL_X_POLYPROP;
>>                 else {
>>                         selinux_log(SELINUX_WARNING,
>>                                     "%s:  line %d has invalid object type %s\n",
>>
>> --
>> Eamon Walsh <ewalsh@tycho.nsa.gov>
>> 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.
>>
>>     
>
>   


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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: [PATCH] libselinux: add "poly_property" type to X contexts backend

[Eamon Walsh]

Eamon Walsh wrote:
> Xavier Toth wrote:
>   
>> I'm curious as to why you chose the route of specifying which
>> properties are polyinstantiated instead of which are not bearing in
>> mind what Glenn said in a previous post?
>>   
>>     
>
> The server will check the "property" lines first and if it doesn't find 
> a match it will check the "poly_property" lines.  So, as long as the 
> wildcard entry in the x_contexts file is changed from property to 
> poly_property, the default will be to polyinstantiate.
>
> However I wasn't planning on treating the root window any differently 
> from other windows, so this behavior would apply to all windows.
>   

Upon further consideration I think I might just add a lookup function to 
the label API that returns the polyinstantiation bit as a separate 
argument.  This could work with files too.

>
>   
>> On Feb 5, 2008 3:30 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>>   
>>     
>>> This patch adds a poly_property type to the X contexts backend, so that
>>> the X Flask module can be informed which properties to polyinstantiate.
>>>
>>> Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
>>> ---
>>>
>>>  include/selinux/label.h |    1 +
>>>  src/label_x.c           |    2 ++
>>>  2 files changed, 3 insertions(+)
>>>
>>>
>>> Index: libselinux/include/selinux/label.h
>>> ===================================================================
>>> --- libselinux/include/selinux/label.h  (revision 2789)
>>> +++ libselinux/include/selinux/label.h  (working copy)
>>> @@ -113,6 +113,7 @@
>>>  #define SELABEL_X_CLIENT       3
>>>  #define SELABEL_X_EVENT                4
>>>  #define SELABEL_X_SELN         5
>>> +#define SELABEL_X_POLYPROP     6
>>>
>>>
>>>  #ifdef __cplusplus
>>> Index: libselinux/src/label_x.c
>>> ===================================================================
>>> --- libselinux/src/label_x.c    (revision 2789)
>>> +++ libselinux/src/label_x.c    (working copy)
>>> @@ -69,6 +69,8 @@
>>>                         data->spec_arr[data->nspec].type = SELABEL_X_EVENT;
>>>                 else if (!strcmp(type, "selection"))
>>>                         data->spec_arr[data->nspec].type = SELABEL_X_SELN;
>>> +               else if (!strcmp(type, "poly_property"))
>>> +                       data->spec_arr[data->nspec].type = SELABEL_X_POLYPROP;
>>>                 else {
>>>                         selinux_log(SELINUX_WARNING,
>>>                                     "%s:  line %d has invalid object type %s\n",
>>>
>>> --
>>> Eamon Walsh <ewalsh@tycho.nsa.gov>
>>> 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.
>>>
>>>     
>>>       
>>   
>>     
>
>
>   


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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: [PATCH] libselinux: add "poly_property" type to X contexts backend

[Glenn Faden]

Eamon Walsh wrote:
> Xavier Toth wrote:
>> I'm curious as to why you chose the route of specifying which
>> properties are polyinstantiated instead of which are not bearing in
>> mind what Glenn said in a previous post?
>>   
>
> The server will check the "property" lines first and if it doesn't 
> find a match it will check the "poly_property" lines.  So, as long as 
> the wildcard entry in the x_contexts file is changed from property to 
> poly_property, the default will be to polyinstantiate.
>
> However I wasn't planning on treating the root window any differently 
> from other windows, so this behavior would apply to all windows.
I've never seen a requirement for polyinstantiation of properties on 
per-client windows. I've seen requirements for relabeling properties, 
however. For example, the trusted selection manager needs to create 
properties that are readable by the client who requests a 
ConvertSelection. We do this by calling a new X protocol extension. How 
do you plan to have trusted clients act on behalf of other clients with 
different security contexts? Similarly, how can a trusted client 
read/write a polyinstantiated property with a different security context?

--Glenn


--
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: [PATCH] libselinux: add "poly_property" type to X contexts backend

[Eamon Walsh]

Glenn Faden wrote:
> Eamon Walsh wrote:
>   
>> Xavier Toth wrote:
>>     
>>> I'm curious as to why you chose the route of specifying which
>>> properties are polyinstantiated instead of which are not bearing in
>>> mind what Glenn said in a previous post?
>>>   
>>>       
>> The server will check the "property" lines first and if it doesn't 
>> find a match it will check the "poly_property" lines.  So, as long as 
>> the wildcard entry in the x_contexts file is changed from property to 
>> poly_property, the default will be to polyinstantiate.
>>
>> However I wasn't planning on treating the root window any differently 
>> from other windows, so this behavior would apply to all windows.
>>     
> I've never seen a requirement for polyinstantiation of properties on 
> per-client windows. I've seen requirements for relabeling properties, 
> however. For example, the trusted selection manager needs to create 
> properties that are readable by the client who requests a 
> ConvertSelection. We do this by calling a new X protocol extension.

SELinux protocol extension allows clients to create windows and 
properties with different security contexts.

>  How 
> do you plan to have trusted clients act on behalf of other clients with 
> different security contexts?

I haven't done the polyinstantiation for selections yet, but my current 
plan is to implement a trusted clipboard manager that will display the 
various clipboard contents and allow users to upgrade or downgrade, 
which means that the clipboard manager will take ownership of the 
selection at the target level and just pipe the data through.  This 
scheme shouldn't require tweaking properties on the fly.  However this 
would not be point-to-point but would make the selection available to 
all applications at the target level.

> Similarly, how can a trusted client 
> read/write a polyinstantiated property with a different security context?
>   

By launching a helper process at the appropriate level.


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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: [PATCH] libselinux: add "poly_property" type to X contexts backend

[Stephen Smalley]

On Tue, 2008-02-05 at 16:30 -0500, Eamon Walsh wrote:
> This patch adds a poly_property type to the X contexts backend, so that 
> the X Flask module can be informed which properties to polyinstantiate.
> 
> Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>

Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>

> ---
> 
>  include/selinux/label.h |    1 +
>  src/label_x.c           |    2 ++
>  2 files changed, 3 insertions(+)
> 
> 
> Index: libselinux/include/selinux/label.h
> ===================================================================
> --- libselinux/include/selinux/label.h	(revision 2789)
> +++ libselinux/include/selinux/label.h	(working copy)
> @@ -113,6 +113,7 @@
>  #define SELABEL_X_CLIENT	3
>  #define SELABEL_X_EVENT		4
>  #define SELABEL_X_SELN		5
> +#define SELABEL_X_POLYPROP	6
>  
> 
>  #ifdef __cplusplus
> Index: libselinux/src/label_x.c
> ===================================================================
> --- libselinux/src/label_x.c	(revision 2789)
> +++ libselinux/src/label_x.c	(working copy)
> @@ -69,6 +69,8 @@
>  			data->spec_arr[data->nspec].type = SELABEL_X_EVENT;
>  		else if (!strcmp(type, "selection"))
>  			data->spec_arr[data->nspec].type = SELABEL_X_SELN;
> +		else if (!strcmp(type, "poly_property"))
> +			data->spec_arr[data->nspec].type = SELABEL_X_POLYPROP;
>  		else {
>  			selinux_log(SELINUX_WARNING,
>  				    "%s:  line %d has invalid object type %s\n",
> 
-- 
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: [PATCH] libselinux: add "poly_property" type to X contexts backend

[Ted X Toth]

Eamon Walsh wrote:
> Glenn Faden wrote:
>> Eamon Walsh wrote:
>>  
>>> Xavier Toth wrote:
>>>    
>>>> I'm curious as to why you chose the route of specifying which
>>>> properties are polyinstantiated instead of which are not bearing in
>>>> mind what Glenn said in a previous post?
>>>>         
>>> The server will check the "property" lines first and if it doesn't 
>>> find a match it will check the "poly_property" lines.  So, as long 
>>> as the wildcard entry in the x_contexts file is changed from 
>>> property to poly_property, the default will be to polyinstantiate.
>>>
>>> However I wasn't planning on treating the root window any 
>>> differently from other windows, so this behavior would apply to all 
>>> windows.
>>>     
>> I've never seen a requirement for polyinstantiation of properties on 
>> per-client windows. I've seen requirements for relabeling properties, 
>> however. For example, the trusted selection manager needs to create 
>> properties that are readable by the client who requests a 
>> ConvertSelection. We do this by calling a new X protocol extension.
>
> SELinux protocol extension allows clients to create windows and 
> properties with different security contexts.
>
>>  How do you plan to have trusted clients act on behalf of other 
>> clients with different security contexts?
>
> I haven't done the polyinstantiation for selections yet, but my 
> current plan is to implement a trusted clipboard manager that will 
> display the various clipboard contents and allow users to upgrade or 
> downgrade, which means that the clipboard manager will take ownership 
> of the selection at the target level and just pipe the data through.  
> This scheme shouldn't require tweaking properties on the fly.  However 
> this would not be point-to-point but would make the selection 
> available to all applications at the target level.
>
This is extremely high on our list of 'must have's and it is critical 
that this be targeted for RHEL6 is this your goal too?

>> Similarly, how can a trusted client read/write a polyinstantiated 
>> property with a different security context?
>>   
>
> By launching a helper process at the appropriate level.
>
>


--
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: [PATCH] libselinux: add "poly_property" type to X contexts backend

[Xavier Toth]

On Wed, Feb 6, 2008 at 1:27 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> Glenn Faden wrote:
>  > Eamon Walsh wrote:
>  >
>  >> Xavier Toth wrote:
>  >>
>  >>> I'm curious as to why you chose the route of specifying which
>  >>> properties are polyinstantiated instead of which are not bearing in
>  >>> mind what Glenn said in a previous post?
>  >>>
>  >>>
>  >> The server will check the "property" lines first and if it doesn't
>  >> find a match it will check the "poly_property" lines.  So, as long as
>  >> the wildcard entry in the x_contexts file is changed from property to
>  >> poly_property, the default will be to polyinstantiate.
>  >>
>  >> However I wasn't planning on treating the root window any differently
>  >> from other windows, so this behavior would apply to all windows.
>  >>
>  > I've never seen a requirement for polyinstantiation of properties on
>  > per-client windows. I've seen requirements for relabeling properties,
>  > however. For example, the trusted selection manager needs to create
>  > properties that are readable by the client who requests a
>  > ConvertSelection. We do this by calling a new X protocol extension.
>
>  SELinux protocol extension allows clients to create windows and
>  properties with different security contexts.
>
>
>  >  How
>  > do you plan to have trusted clients act on behalf of other clients with
>  > different security contexts?
>
>  I haven't done the polyinstantiation for selections yet, but my current
>  plan is to implement a trusted clipboard manager that will display the
>  various clipboard contents and allow users to upgrade or downgrade,
>  which means that the clipboard manager will take ownership of the
>  selection at the target level and just pipe the data through.  This
>  scheme shouldn't require tweaking properties on the fly.  However this
>  would not be point-to-point but would make the selection available to
>  all applications at the target level.
>


Are you thinking of starting with an existing clipboard manager like Glipper?


>
>  > Similarly, how can a trusted client
>  > read/write a polyinstantiated property with a different security context?
>  >
>
>  By launching a helper process at the appropriate level.
>
>
>  --
>
>
> Eamon Walsh <ewalsh@tycho.nsa.gov>
>  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: [PATCH] libselinux: add "poly_property" type to X contexts backend

[Eamon Walsh]

Ted X Toth wrote:
> Eamon Walsh wrote:
>   
>> Glenn Faden wrote:
>>     
>>> Eamon Walsh wrote:
>>>  
>>>       
>>>> Xavier Toth wrote:
>>>>    
>>>>         
>>>>> I'm curious as to why you chose the route of specifying which
>>>>> properties are polyinstantiated instead of which are not bearing in
>>>>> mind what Glenn said in a previous post?
>>>>>         
>>>>>           
>>>> The server will check the "property" lines first and if it doesn't 
>>>> find a match it will check the "poly_property" lines.  So, as long 
>>>> as the wildcard entry in the x_contexts file is changed from 
>>>> property to poly_property, the default will be to polyinstantiate.
>>>>
>>>> However I wasn't planning on treating the root window any 
>>>> differently from other windows, so this behavior would apply to all 
>>>> windows.
>>>>     
>>>>         
>>> I've never seen a requirement for polyinstantiation of properties on 
>>> per-client windows. I've seen requirements for relabeling properties, 
>>> however. For example, the trusted selection manager needs to create 
>>> properties that are readable by the client who requests a 
>>> ConvertSelection. We do this by calling a new X protocol extension.
>>>       
>> SELinux protocol extension allows clients to create windows and 
>> properties with different security contexts.
>>
>>     
>>>  How do you plan to have trusted clients act on behalf of other 
>>> clients with different security contexts?
>>>       
>> I haven't done the polyinstantiation for selections yet, but my 
>> current plan is to implement a trusted clipboard manager that will 
>> display the various clipboard contents and allow users to upgrade or 
>> downgrade, which means that the clipboard manager will take ownership 
>> of the selection at the target level and just pipe the data through.  
>> This scheme shouldn't require tweaking properties on the fly.  However 
>> this would not be point-to-point but would make the selection 
>> available to all applications at the target level.
>>
>>     
> This is extremely high on our list of 'must have's and it is critical 
> that this be targeted for RHEL6 is this your goal too?
>   

Yes, for the server side.  However I have no timeline for the trusted 
clipboard manager application.

Something like Glipper might be a good place to start.  What will be 
needed is to make it aware that the same selection (e.g. PRIMARY) may be 
owned by different clients at different levels, and implement the 
downgrading/upgrading feature.

>   
>>> Similarly, how can a trusted client read/write a polyinstantiated 
>>> property with a different security context?
>>>   
>>>       
>> By launching a helper process at the appropriate level.
>>
>>
>>     
>
>
> --
> 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.
>
>   


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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.