Re: Nautilus integration with SELinux




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.







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]