On Mon, 2008-03-17 at 16:16 -0400, Tim Taylor wrote:
On Mon, 2008-03-17 at 08:07 -0400, Stephen Smalley wrote:
> On Mon, 2008-03-17 at 11:31 +0000, Paul Howarth wrote:
> > ttaylor wrote:
> > > Does anything special have to be done to cause SELinux to start
> using newly
> > > added local filecontexts? What I'm finding is that if I use
> > > fcontext -a to add a local filecontext definition, it is not used
> > > restorecon unless I specify the "-F" option. Without the
> > > restorecon -vv <file_path> gives the following message:
> > >
> > > /sbin/restorecon: <file_path> not reset customized by admin to
> > > <current_context>
> > >
> > > but restorecon -vv -F <file_path> gives this:
> > >
> > > /sbin/restorecon reset <file_path> context
> > This is probably because <current_context> is a customizable type
> > httpd_sys_content_t; objects with these types don't get reset by
> > restorecon unless you use -F. I'm not sure how to find out which
> > are customizable off the top of my head though.
> cat /etc/selinux/$SELINUXTYPE/contexts/customizable_types
> Dan - I thought we had discussed reducing that set significantly since
> it was originally to avoid clobbering locally-set types upon a
> filesystem relabel prior to the introduction of semanage, but with
> now able to add local file contexts easily via semanage fcontext -a,
> isn't as necessary.
This is exactly my situation. I am using Fedora 8 with all the latest
updates. I had used semanage to add a filecontext which would cause
particular directories to be labeled with the type httpd_sys_script_rw_t
which is a customizable type.
The directory I was trying to label was under /var/www which has a
context of httpd_sys_content_t which is also a customizabile type. So
why is it that new directories under /var/www are automatically labeled
with the httpd_sys_content_t type, but things that match my added
filecontext don't automatically get labeled with httpd_sys_script_rw_t,
and require the use of restorecon -F?
Here's the specifics:
The command I used to add my local context:
semanage fcontext -d -f -d -t httpd_sys_script_rw_t
This adds the entry to your file contexts configuration, a mapping from
pathname regexes to file security contexts that is used to determine the
right security context for a file when it is first installed (e.g. by
rpm) or when you want to reset the filesystem to its initial state (e.g.
via restorecon or fixfiles relabel), but not at runtime by the kernel.
I then create a directory that matches the above pattern:
mkdir -p /var/www/wikis/foo/images
The directory is created, but has the type httpd_sys_content_t.
For runtime file creation, the kernel labels new files based on either:
1) a type transition rule in the policy if one exists for the creating
process' domain, the parent directory type, and the new file's security
class (object type - e.g. regular file, directory, symlink, device
2) the parent directory's type if no type transition rule matches.
The file contexts configuration is not used by the kernel and is only
supposed to represent the initial install-time state of the filesystem.
Now I use restorecon to relabel:
restorecon -vv /var/www/wikis/foo/images
restorecon does consult the file contexts configuration.
This gives me the following message:
/sbin/restorecon: /var/www/wikis/foo/images not reset customized by
admin to system_u:object_r:httpd_sys_content_t:s0
This is because the existing type on the file is a customizable type and
thus may have been manually set by the admin via chcon - this approach
predates the introduction of semanage and as Dan said, customizable
types has been dropped in rawhide / Fedora 9, so you won't encounter
this problem going forward there.
Now run restorecon with the force flag:
restorecon -vv -F /var/www/wikis/foo/images
Gives this message:
restorecon reset /var/www/wikis/foo/images context
Since both types are in the customizable_types file, why is one
automatically used, and the other only used when forced?
If by automatically used, you mean at new file creation, neither file
contexts nor customizable types has anything to do with that. If you
mean by restorecon, the restorecon logic is simply to not relabel a file
that has a customizable type since it may have been manually set by the
National Security Agency