Re: Nautilus integration with SELinux

[Ivan Gyurdiev <ivg2 cornell edu>]

> We're already facing the problem of complexity with the standard UNIX
> permissions. Very few people actually know what the r and x flag means
> for directories. You can't expect people to be aware of complex issues,
> and that's the whole problem with security. Innovative concepts are
> appreciated, but when designing some proposals for the new UI, I
> immediately faced the problem that there are people who know exactly
> what they're doing and people who don't have a glimpse about the details
> but just want to be able to read something/write to some location, or be
> able to prevent others from reading from/writing to a location, a
> document, a share or whatever.
>   
What about the following: Two fields, each with a drop down box/list of 
enumerated items, which allows scrolling, and searching.
Forget enumeration for the moment, it appears we won't be able to unroll 
the MLS range into (s,c) pairs, so a different approach might be needed 
which lists valid combinations of categories - that's what I was 
referring to when I said more discussion is necessary w/ nsa-list.

1. Security Type [ The available list is defined by the current security 
policy, and user access rights ].

Currently: samba_share_t, http_user_content_t
Possibly: Samba Share, HTTP Content, Office Document, Untrusted Content 
[ from the web, viruses... ], Music File... (translated?)

2. Security Clearances Required [ The available list and "unrolling" is 
defined by the sysadmin, and user access rights ].

ex: Red Hat Nautilus [ unrolls internally to require all of: Developer, 
Red Hat, Nautilus Project ]
ex: NASA Secret Project [ unrools internally to require all of: NASA, 
Scientist, Confidential ]
ex: Security Administrator [ unrolls internally to require all of: 
Administrator, Security, User ]

I don't understand why this is perceived as being so complicated...
It seems simpler than DAC permissions, if implemented properly [ I'll 
likely need to add more infrastructure to our libsetrans translation 
library, which is supposed to make things easy to use ].
> I'd appreciate an integration of a sophisticated technologies like
> SElinux, but the limits of GUI simplification begin where admin issues
> are involved. It is probably very hard to expose the full MAC power in a
> button/list-driven GUI rather than a shell (wrapper?),although MCS
>   
> seems to be more intuitive to the user than MLS. According to Wikipedia,
> RH is mainly interested in using SElinux for server services, so why
> should the ordinary user care? 
The ordinary user does care about security - ask any Windows user who 
has had trouble with viruses.
SELinux at this point does not attempt to confine the desktop, because 
it's not very mature, this would be difficult. However it certainly may 
do so in the future, and then nautilus integration will be important. 
One of the things we're interested in doing is keeping track of 
potentially hostile content, which originated from the Internet, and 
alterting the user about dangers as he manipulate this content with 
desktop applications. Integration with a virus scanner has been suggested.

Even right now, MCS integration will be useful to provide more 
flexibility than Unix groups. The ability to change the SELinux type 
will be useful to deal with SELinux-confined servers, which expect 
certain security settings to work properly.

> Maybe you could come up with concrete
> use-cases, apart from intelligence/government applications, where the
> user actually wants to apply/modify the categories for a particular
> file?
>   
Category support is not limited to intelligence/government applications. 
It's applicable to any environment, where flexibility is required in 
designating what can be shared, and with whom. See some of the examples 
I listed above.

More examples:
A doctor might want to mark his document as Patient_Confidential, so 
that only persons with this clearance can access this.
A teacher might want to mark his files [ CS434_Access to unroll to: 
Student, Computer Science,  CS434, Assignment 3 ]
...

I think integration with the printing system is planned, so that 
sensitivities and categories can be printed on paper documents if the 
user desires, to track confidentiality requirements in paper form.