Desktop integration

Desktop integration

[Ivan Gyurdiev]

Hi, my new project (part of it anyway) is to work on desktop 
integration, particularly nautilus and openoffice. We want to display 
(parts of) the security context, and make them configurable by the user. 
Specifically, we're thinking about exposing the type field, and the MCS 
field.

However I am still not happy with the infrastructure we have to support 
that kind of thing, so I wanted to see what others think about this.

The read interface will be easy (hopefully), but the write interface is 
not clear. I think we want to aim for user-friendly selinux. For 
categories, one possibility is to enumerate the translation strings from 
setrans.conf, and have checkboxes for each that the user can click (I 
like this idea). Another way to deal with this is a text box, where we 
can enter translated or untranslated categories and/or ranges.

For the type field, it makes sense to me to have a drop-down box with 
the customizable types in there (as the user shouldn't relabeling to any 
other types). I also think we should translate those types into 
something more user friendly, possibly in multiple languages. I imagine 
a box that you can choose from "Office Document", "Music File", "Image 
FIle", "Sensitive Data", "Untrusted Content", things like that. Any 
other suggestions?

Maybe the nautilus/GNOME list would be a better place to discuss some of 
those things, but I am also interested in the infrastructure that we'll 
need. What needs to be added, and which libraries should it go to? I 
like the idea of making enhancements to libsetrans. Why doesn't this 
library have a clear API with namespace and headers? Will I need to 
replicate my database_file.c code in there? I think we need a way to 
enumerate setrans entires (other than the python semanage utility), 
enumerate customizable types, and translate customizable types.

--
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: Desktop integration

[Daniel J Walsh]

Ivan Gyurdiev wrote:
> Hi, my new project (part of it anyway) is to work on desktop 
> integration, particularly nautilus and openoffice. We want to display 
> (parts of) the security context, and make them configurable by the 
> user. Specifically, we're thinking about exposing the type field, and 
> the MCS field.
>
> However I am still not happy with the infrastructure we have to 
> support that kind of thing, so I wanted to see what others think about 
> this.
>
> The read interface will be easy (hopefully), but the write interface 
> is not clear. I think we want to aim for user-friendly selinux. For 
> categories, one possibility is to enumerate the translation strings 
> from setrans.conf, and have checkboxes for each that the user can 
> click (I like this idea). Another way to deal with this is a text box, 
> where we can enter translated or untranslated categories and/or ranges.
seobject.py currently does this, but of course it is written in python.

It basically does a getcon on the process and then takes it MLSRange 
potion and translates it into reachable contexts

s0-s0:c1.c5  = s0. s0:c1, s0:c2, s0:c3, s0:c4, s0:c5. 

It then attempts to translate each one of these to show the user which 
categories he can create files in.
>
> For the type field, it makes sense to me to have a drop-down box with 
> the customizable types in there (as the user shouldn't relabeling to 
> any other types). I also think we should translate those types into 
> something more user friendly, possibly in multiple languages. I 
> imagine a box that you can choose from "Office Document", "Music 
> File", "Image FIle", "Sensitive Data", "Untrusted Content", things 
> like that. Any other suggestions?

>
> Maybe the nautilus/GNOME list would be a better place to discuss some 
> of those things, but I am also interested in the infrastructure that 
> we'll need. What needs to be added, and which libraries should it go 
> to? I like the idea of making enhancements to libsetrans. Why doesn't 
> this library have a clear API with namespace and headers? Will I need 
> to replicate my database_file.c code in there? I think we need a way 
> to enumerate setrans entires (other than the python semanage utility), 
> enumerate customizable types, and translate customizable types.


Changing types is a tougher problem.  First you are making two bad 
assumptions.

1. That a user can relabel to all of the customizable types.  In most 
policies he will not be allowed to .

2. That the only types he can relabel to are customizable.

For  example user_home_t is not necessarily customizable but a user 
could change a context to it.

Until we get a better interface I think you have at best the option to 
allow the user to

Restore System Defaults on a file (Restorecon)

Or prompt them for the context they want to change to.

We could make an assumption that httpd_user_* are available options 
since this would seem to be the most likely context a user would want to 
set.




--
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: Desktop integration

[Ivan Gyurdiev]

>>
>> The read interface will be easy (hopefully), but the write interface 
>> is not clear. I think we want to aim for user-friendly selinux. For 
>> categories, one possibility is to enumerate the translation strings 
>> from setrans.conf, and have checkboxes for each that the user can 
>> click (I like this idea). Another way to deal with this is a text 
>> box, where we can enter translated or untranslated categories and/or 
>> ranges.
> seobject.py currently does this, but of course it is written in python.
>
> It basically does a getcon on the process and then takes it MLSRange 
> potion and translates it into reachable contexts
>
> s0-s0:c1.c5  = s0. s0:c1, s0:c2, s0:c3, s0:c4, s0:c5.
> It then attempts to translate each one of these to show the user which 
> categories he can create files in.
You're right, I'm not making any sense.. was confused, thinking of a 
different issue.
Should we add a utility function in libselinux that does this kind of 
expand/translate processing?


--
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: Desktop integration

[Thomas Bleher]

* Daniel J Walsh <dwalsh@redhat.com> [2006-01-30 20:33]:
> Ivan Gyurdiev wrote:
> >For the type field, it makes sense to me to have a drop-down box with 
> >the customizable types in there (as the user shouldn't relabeling to 
> >any other types). I also think we should translate those types into 
> >something more user friendly, possibly in multiple languages. I 
> >imagine a box that you can choose from "Office Document", "Music 
> >File", "Image FIle", "Sensitive Data", "Untrusted Content", things 
> >like that. Any other suggestions?
> 
> Changing types is a tougher problem.  First you are making two bad 
> assumptions.
> 
> 1. That a user can relabel to all of the customizable types.  In most 
> policies he will not be allowed to .
> 
> 2. That the only types he can relabel to are customizable.

Wouldn't it be better to look up the allowed relabels directly? 
You'd first have to check if the user has "relabelfrom" rights on the
file and then collect all the file types for which the user has
"relabelto" rights.
This is could be done with compute_av, but I don't think we want to
allow users to do this.

IMHO it would be best to create a new interface to query the policy for
this type of information. Maybe not in the kernel, but the policy server
surely could provide it.

Thomas

--
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: Desktop integration

[Joshua Brindle]

Thomas Bleher wrote:
> * Daniel J Walsh <dwalsh@redhat.com> [2006-01-30 20:33]:
>> Ivan Gyurdiev wrote:
>>> For the type field, it makes sense to me to have a drop-down box with 
>>> the customizable types in there (as the user shouldn't relabeling to 
>>> any other types). I also think we should translate those types into 
>>> something more user friendly, possibly in multiple languages. I 
>>> imagine a box that you can choose from "Office Document", "Music 
>>> File", "Image FIle", "Sensitive Data", "Untrusted Content", things 
>>> like that. Any other suggestions?
>> Changing types is a tougher problem.  First you are making two bad 
>> assumptions.
>>
>> 1. That a user can relabel to all of the customizable types.  In most 
>> policies he will not be allowed to .
>>
>> 2. That the only types he can relabel to are customizable.
> 
> Wouldn't it be better to look up the allowed relabels directly? 
> You'd first have to check if the user has "relabelfrom" rights on the
> file and then collect all the file types for which the user has
> "relabelto" rights.
> This is could be done with compute_av, but I don't think we want to
> allow users to do this.
> 
> IMHO it would be best to create a new interface to query the policy for
> this type of information. Maybe not in the kernel, but the policy server
> surely could provide it.
> 

To clarify, the policy management server does not perform av lookups for 
the user. It will make the exposed policy components (users, ports, 
booleans, etc) available through a client (semanage, semodule) and 
enforce access controls on policy updates.

I don't think it makes sense to duplicate permission information into an 
semanage database. However a helper app can easily do compute_av's on 
behalf of the user in a privileged domain from either the kernel 
security server or later on the userspace security server.

Rather than trying to query every file type a user has access to 
relabel, which may be a little time consuming and give make the 
interface practically unusable (almost every type is relabel able 
to/from by sysadm_t) it should be limited to customizable or some 
superset of customizable.

This is probably best accomplished using dbus so that the desktop apps 
(running as the user domain?) don't maintain their own netlink 
connection to the kss but still know when the avc has been flushed and 
new av checks must be done (via the helper app over dbus).

--
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: Desktop integration

[Ivan Gyurdiev]

>
>
> 1. That a user can relabel to all of the customizable types.  In most 
> policies he will not be allowed to .
That's fair enough, but it can be checked...
>
> 2. That the only types he can relabel to are customizable.
> For  example user_home_t is not necessarily customizable but a user 
> could change a context to it.
>
I don't understand this one. Why is the user allowed to relabel to a 
non-customizable type.

Something's wrong with this - it appears to carry a risk that the file 
will be automatically relabeled later, even after the user has made an 
explicit request that it must be labeled user_home_t - that certainly 
seems like a bad thing.

--
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: Desktop integration

[Daniel J Walsh]

Ivan Gyurdiev wrote:
>
>>
>>
>> 1. That a user can relabel to all of the customizable types.  In most 
>> policies he will not be allowed to .
> That's fair enough, but it can be checked...
>>
>> 2. That the only types he can relabel to are customizable.
>> For  example user_home_t is not necessarily customizable but a user 
>> could change a context to it.
>>
> I don't understand this one. Why is the user allowed to relabel to a 
> non-customizable type.
>
> Something's wrong with this - it appears to carry a risk that the file 
> will be automatically relabeled later, even after the user has made an 
> explicit request that it must be labeled user_home_t - that certainly 
> seems like a bad thing.
Usually the user would be changing a badly labeled file back to 
user_home_t in his home directory.  So if a user changes a context to a 
customizable type, he might want to later change the context back.   
user_home_t should not be a customizable type, because a user could 
create a file in his home dir and then mv it to /var/www/html for 
example.  We would not want that context to remain user_home_t.



--
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: Desktop integration

[Ivan Gyurdiev]

>>>
>>> 2. That the only types he can relabel to are customizable.
>>> For  example user_home_t is not necessarily customizable but a user 
>>> could change a context to it.
>>>
>> I don't understand this one. Why is the user allowed to relabel to a 
>> non-customizable type.
>>
>> Something's wrong with this - it appears to carry a risk that the 
>> file will be automatically relabeled later, even after the user has 
>> made an explicit request that it must be labeled user_home_t - that 
>> certainly seems like a bad thing.
> Usually the user would be changing a badly labeled file back to 
> user_home_t in his home directory.  So if a user changes a context to 
> a customizable type, he might want to later change the context back.   
Customizable types won't prevent you from changing the context back - 
they'll just prevent restorecon from changing its type.
> user_home_t should not be a customizable type, because a user could 
> create a file in his home dir and then mv it to /var/www/html for 
> example.  We would not want that context to remain user_home_t.
Why not? I don't like it when restorecon tries to be extra smart.
The user should make an explicit request to expose his files to the web 
(via chcon), rather than  relying on automated relabeling with 
restorecon, which seems like it should be used for a completely 
different purpose.

--
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: Desktop integration

[Daniel J Walsh]

Ivan Gyurdiev wrote:
>
>>>>
>>>> 2. That the only types he can relabel to are customizable.
>>>> For  example user_home_t is not necessarily customizable but a user 
>>>> could change a context to it.
>>>>
>>> I don't understand this one. Why is the user allowed to relabel to a 
>>> non-customizable type.
>>>
>>> Something's wrong with this - it appears to carry a risk that the 
>>> file will be automatically relabeled later, even after the user has 
>>> made an explicit request that it must be labeled user_home_t - that 
>>> certainly seems like a bad thing.
>> Usually the user would be changing a badly labeled file back to 
>> user_home_t in his home directory.  So if a user changes a context to 
>> a customizable type, he might want to later change the context back.   
> Customizable types won't prevent you from changing the context back - 
> they'll just prevent restorecon from changing its type.
>> user_home_t should not be a customizable type, because a user could 
>> create a file in his home dir and then mv it to /var/www/html for 
>> example.  We would not want that context to remain user_home_t.
> Why not? I don't like it when restorecon tries to be extra smart.
> The user should make an explicit request to expose his files to the 
> web (via chcon), rather than  relying on automated relabeling with 
> restorecon, which seems like it should be used for a completely 
> different purpose.
Because the user does not understand.  He creates a cgi script in his 
home directory or /tmp and then mv's it to /var/www/cgi-bin or 
/var/www/html.  In his mind the act of moving it to /var/www/html is the 
act of sharing it.  So
having him figure out that the context should be httpd_sys_content_t is 
just a burden.  Similarly if he moves a local copy of
resolv.conf from his homedir to /etc. and runs restorecon it will not work.


I guess having the list of customizable types plus "Default" would 
work.  Default running or executing the equivalent of restorecon.

Dan

--
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: Desktop integration

[Erich Schubert]

Hi,
> Because the user does not understand.  He creates a cgi script in his 
> home directory or /tmp and then mv's it to /var/www/cgi-bin or 
> /var/www/html.  In his mind the act of moving it to /var/www/html is the 
> act of sharing it.  So

I agree here a lot. We need to think more of the user, too. Security is
worthless when people don't understand it and then just disable it,
because they don't get how to properly use it.

A somewhat related question: Does SELinux have a measure to _prohibit_
certain "file type nestings"?
Right now I think you can basically label any file with any file label;
you'll probably break apps and such, but that is up to you.
But for example, why should files outside of /var be allowed to have any
var_*_t file type? or even bin_t - right now you can label a file
in /var/tmp bin_t, which I really do not want to allow... But it's also
a question at how expensive it is to prohibit.
But I guess the kernel could be equipped with a set of rules that
basically say inode foo maybe labeled bar only if it's parent inodes
have label quux. Gets very complicated however with hard links...

But we could use this at least to prevent the just described problem of
introducing mislabeled files by editing files in a different dir and
then copying them over...

best regards,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
   To understand recursion you first need to understand recursion.   //\
  Wer nicht zuweilen zuviel empfindet, der empfindet immer zuwenig.  V_/_


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