On Mon, Jan 10, 2005 at 01:50:49PM -0700, Ivan Gyurdiev wrote:
> Why doesn't SElinux support multiple contexts per file?
> It seems to me that this feature would be very useful.
> Is this technically not feasible?
>
> I've been trying to get the following setup working on FC3 (rawhide):
>
> /var/www/html.userX -
> virtual server for userX.mydomain labeled httpd_sys_content_t
> /home/userX -
> home folder for userX, exported via Samba (not yet, but
> it will be, once dwalsh puts in booleans for samba reading home)
>
> /home/userX/webserver - symlink to /var/www/html.userX
>
> Now, /var/www/html.userX needs to be accessed both by smbd and httpd.
> I need to label it with both samba_share_t and httpd_sys_content_t.
 

 i understand the mindset of selinux enough now to be able to say that  the recommended approach would be for you to create a file type  samba_share_httpd_sys_content_t and then for you to modify the  selinux policy to grant the programs requiring access to those  filetypes in the samba.te and the apache.te policy files.

> I have to edit the cryptic m4 policy file to add a type that's
> accessible by both. Why is this necessary? Why can't selinux
> either

> (1) Label the file with both contexts, and permit
> the operation if any context permits it
>
> or
>
> (2) Create a type with the properties of both
> with less user interaction (without needing to
> modify the policy manually)
>
> Since I'm unfamiliar with how SElinux works internally,
> this might be a stupid question, but it seems to me that
> the user should not be required to understand how a policy
> file works to label a file for use by two restricted programs.

 yes, it does seem a little curious: taking NT security descriptors  (actually VMS SDs) as an example, and ignoring the fact that NT/VMS  SDs contain DAC (discretionary) ACLs - each ACL is just that - an  access control LIST.

 whereas in NT, the SD contains ACLs and the ACLs can be extended,  modified and edited (and are better understood!), SElinux turns things  roundabout somewhat: providing a reference (handle) into a binary  policy.

 what i _am_ aware of is that by having the policies in a structured  language, formal analysis tools can be applied to make certain  guarantees and proofs.

 in paranoid security environments, it's far more important  to be able to prove that someone _could_ break in than to  not _know_ if they could break in (!)

 i can only hazard a hazardous guess therefore that the more  "normal" ACL system [that we are used to seeing] was rejected  because it makes the formal proof methodology more difficult.

 *shrug*. *clueless*. anyone know?

 l.

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