Re: preserving user-set contexts

[Joshua Brindle <jbrindle@snu.edu>]

This xattr could be protected by selinux couldn't it?

user.selinux could be 0 or 1 and selinux_inode_security could be 
modified to apply policy to setting this attribute..

So not only would there be DAC restrictions we could also enforce 
writing the label only on files that the user has the ability to relabel 
  to.

Joshua Brindle

Colin Walters wrote:

> On Mon, 2004-04-26 at 10:30, Stephen Smalley wrote:
> 
> 
>>It wouldn't be safe to allow untrusted users to mark files in this
>>manner, as it could prevent proper relabeling of the filesystem upon a
>>policy update.  
> 
> 
> Well, users should still be stopped by DAC in setting xattrs on files
> they didn't own, which covers all the practical cases I can think of
> right now.  But it would be nice to have a SELinux solution to this, see
> below.
> 
> 
>>So you would have to limit it to administrators anyway. 
> 
> 
> A much better example than the /build one I gave originally is
> httpd_user_content_t.  Users should be able to use chcon to change the
> types of specific files in their home directory to allow the webserver
> access.  Right now, an administrator running setfiles will blow away all
> of those changes and reset them to user_home_t.  I think this is going
> to be pretty undesirable in almost all situations.  Certainly an admin
> should be able to reset all these types if they desire, but I don't
> think it makes sense as the default.
> 
> As more policy is written I'm sure there will be other examples of types
> that are useful to users.
> 
> 
>>And if they are administrators, they can already mark the files with
>><<none>> in the file contexts configuration.  
> 
> 
> I don't think administrators should generally have to edit
> file_contexts.  The whole idea of using xattrs is that it makes
> management much easier.  And especially for user-set contexts like
> httpd_user_content_t, one can't expect the administrator to track every
> user's web content.
> 
> 
>>You could also introduce a
>>separate type in the policy that setfiles doesn't have permission to
>>relabelfrom, and use that type for this purpose.
> 
> 
> But that would lose the distinction between all user-changeable types;
> it doesn't make sense to me.
> 
> 
>>I don't think it is the right approach.  
> 
> 
> Ok.  For the /build problem, we could add an option for setfiles to
> simply ignore unknown files instead of using default_t.  For the
> httpd_user_content_t problem, we could add an attribute e.g.
> "customizable_type".  setfiles would by default not relabel that have
> this type.
> 
> 


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