preserving user-set contexts

preserving user-set contexts

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

Hi,

Often I manually change file contexts; for example, I create a toplevel
/build directory where I store random binary builds I create.  Right now
I just use staff_home_t so my regular user can access it.  However, if I
was ever to do a 'make relabel', all of those contexts would get blown
away and reset to default_t.

What I think would be nice is if we had chcon set another extended
attribute that marked the file as having its context manually set.  Then
we modify setfiles to ignore files which have this extended attribute by
default.  That way I could use 'make relabel' to fix system contexts,
and leave my customizations intact.

Probably this would involve a libselinux API addition for setfilecon,
perhaps setfilecon_user.

Is this desirable?  Does it seem like the right approahc?  One question
is - which namespace to put it in?  user.?  system.?  If we allow
regular users to relabel (as we already do for files like
httpd_user_script_exec_t) then we can only put it in the user.
namespace.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: preserving user-set contexts

[Stephen Smalley]

On Fri, 2004-04-23 at 16:37, Colin Walters wrote:
> What I think would be nice is if we had chcon set another extended
> attribute that marked the file as having its context manually set.  Then
> we modify setfiles to ignore files which have this extended attribute by
> default.  That way I could use 'make relabel' to fix system contexts,
> and leave my customizations intact.

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.  So you would have to limit it to administrators anyway. 
And if they are administrators, they can already mark the files with
<<none>> in the file contexts configuration.  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.

> Is this desirable?  Does it seem like the right approahc?  One question
> is - which namespace to put it in?  user.?  system.?  If we allow
> regular users to relabel (as we already do for files like
> httpd_user_script_exec_t) then we can only put it in the user.
> namespace.

I don't think it is the right approach.  But note that the security
namespace is easily extensible, so you can create additional security
attributes in it for other purposes without requiring changes to the
kernel.  Use of the security namespace requires CAP_SYS_ADMIN except for
the SELinux attribute, which has its own finer-grained permissions.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: preserving user-set contexts

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

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.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: preserving user-set contexts

[Joshua Brindle]

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.

Re: preserving user-set contexts

[Stephen Smalley]

On Wed, 2004-04-28 at 00:05, Joshua Brindle wrote:
> 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.

Using the "user" namespace may be inappropriate, given its intended
usage and access control model per attr(5).  Adding another attribute
under the "security" namespace and altering selinux_inode_setxattr and
selinux_inode_removexattr to check a new permission to the file when
setting this attribute would be possible, but I'm not convinced that
this is desirable.

A simpler alternative would be to support two variants of the file
contexts configuration; one for initial install labeling and one for
runtime relabeling, and if the administrator is ok with users being able
to customize their home directories, then he can mark /home as <<none>>
in the config for runtime relabeling so that any local customizations in
home directories will always be preserved.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: preserving user-set contexts

[Stephen Smalley]

On Tue, 2004-04-27 at 21:44, Colin Walters wrote:
> 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.

DAC isn't applied to the security namespace.  SELinux controls access to
its attributes (including an identity-based restriction on
relabelfrom/relabelto via policy/constraints).  Other attributes in the
security namespace are presently limited to CAP_SYS_ADMIN.

And relying on DAC to prevent the ability to _block_ a MAC policy from
being applied is not a good idea anyway.  At the very least, uid 0 is
troublesome.

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

That's debatable.  Many MAC policies aren't going to allow ordinary
users to relabel _anything_.  And allowing users to export arbitrary
data to the web server is not a good idea, if you want to enforce any
kind of confidentiality policy.

> Ok.  For the /build problem, we could add an option for setfiles to
> simply ignore unknown files instead of using default_t.

setfiles already skips files that have no matching specification.  But
at present, every file matches at least the /.* regex at the beginning
of types.fc.  So you can achieve the above by simply removing that
pattern (but I wouldn't recommend this).  Note that even if you do this,
you'll still want some context applied for the initial install.  So
you'll need two variants of the file_contexts configuration; one for
installation and one for runtime relabels (which isn't necessarily a bad
idea anyway).

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

And how do you control the ability to set this attribute?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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: preserving user-set contexts

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]

On Wed, 2004-04-28 at 07:49, Stephen Smalley wrote:
> On Tue, 2004-04-27 at 21:44, Colin Walters wrote:
> > 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.
> 
> DAC isn't applied to the security namespace.  SELinux controls access to
> its attributes (including an identity-based restriction on
> relabelfrom/relabelto via policy/constraints).  Other attributes in the
> security namespace are presently limited to CAP_SYS_ADMIN.
> 
> And relying on DAC to prevent the ability to _block_ a MAC policy from
> being applied is not a good idea anyway.

I agree.

> That's debatable.  Many MAC policies aren't going to allow ordinary
> users to relabel _anything_.  

Well, presently the sample policy does.  I recently added another
user-customizable type to the Red Hat policy, e.g.
staff_mount_source_t.  I think that other types like this will be
created in the future as well.

> And allowing users to export arbitrary
> data to the web server is not a good idea, if you want to enforce any
> kind of confidentiality policy.

True.  But it seems to me that without something like MLS, it is
currently difficult to enforce a reasonable and strong confidentiality
policy using SELinux anyways.

> setfiles already skips files that have no matching specification.  But
> at present, every file matches at least the /.* regex at the beginning
> of types.fc.  So you can achieve the above by simply removing that
> pattern (but I wouldn't recommend this).  Note that even if you do this,
> you'll still want some context applied for the initial install.  So
> you'll need two variants of the file_contexts configuration; one for
> installation and one for runtime relabels (which isn't necessarily a bad
> idea anyway).

Yes, the two variants idea sounds reasonable to me for the /build
problem.

> >   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.
> 
> And how do you control the ability to set this attribute?

Ah, sorry; I meant a SELinux policy attribute, not an xattr.  So
checkpolicy could gather these and perhaps write out a separate
"customizable_types" file.  setfiles would parse this and by default not
relabel files with one of these types.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: preserving user-set contexts

[kris-selinux]

On Wed, Apr 28, 2004 at 09:13:10AM -0400, Colin Walters wrote:
> > >   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.
> > 
> > And how do you control the ability to set this attribute?
> 
> Ah, sorry; I meant a SELinux policy attribute, not an xattr.  So
> checkpolicy could gather these and perhaps write out a separate
> "customizable_types" file.  setfiles would parse this and by default not
> relabel files with one of these types.
> 
possibly a more restrictive setup with pairs of types where setfiles
will not relabel a file to the target type if it's current source type
is an allowed variant.  i.e. (From the Debian policy which I'm not
actually using so I might be getting this very wrong...)

	httpd_user_script_ro_t  ->  httpd_user_content_t
	httpd_user_script_rw_t  ->  httpd_user_content_t
	httpd_user_script_ra_t  ->  httpd_user_content_t

then any file covered by a regexp for httpd_user_content_t will not be
relabelled if it's current type is httpd_user_script_r[oaw]_t;

-- 
Kris Shannon <kris@sisgroup.com.au>


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