6:11 p.m.
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 semanage
fcontext -a to add a local filecontext definition, it is not used by
restorecon unless I specify the "-F" option. Without the "-F"
option,
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
<current_context>-><new_context>
I've also tried using /usr/sbin/semodule --build to try rebuilding (and
reloading) the current policy, but that
didn't change the behavior I'm seeing.
Any suggestions would be greatly appreciated.
- Tim
--
View this message in context:
http://www.nabble.com/Question-on-semanage-fcontext--a-tp15240526p1605831...
Sent from the Fedora SELinux List mailing list archive at Nabble.com.
6:31 a.m.
New subject: Question on semanage fcontext -a
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 semanage
fcontext -a to add a local filecontext definition, it is not used by
restorecon unless I specify the "-F" option. Without the "-F"
option,
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
<current_context>-><new_context>
This is probably because <current_context> is a customizable type like
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 types
are customizable off the top of my head though.
Paul.
7:07 a.m.
New subject: Question on semanage fcontext -a
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 semanage
> fcontext -a to add a local filecontext definition, it is not used by
> restorecon unless I specify the "-F" option. Without the "-F"
option,
> 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
<current_context>-><new_context>
This is probably because <current_context> is a customizable type like
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 types
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 users
now able to add local file contexts easily via semanage fcontext -a, it
isn't as necessary.
--
Stephen Smalley
National Security Agency
9:14 a.m.
New subject: Question on semanage fcontext -a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 semanage
fcontext -a to add a local filecontext definition, it is not used by
restorecon unless I specify the "-F" option. Without the "-F"
option,
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
<current_context>-><new_context>
I've also tried using /usr/sbin/semodule --build to try rebuilding (and
reloading) the current policy, but that
didn't change the behavior I'm seeing.
Any suggestions would be greatly appreciated.
- Tim
The only time you should need the -F would be if the previous context
was in /etc/selinux/targeted/contexts/customizable_types
I believe. The most common of these are httpd. This file is an
artifact of what we had to do before we had semanage.
If the file context is not listed in this file and you still need the
force, what is the the file context you are changing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkfefN4ACgkQrlYvE4MpobPlVgCcDsqC/AOjwJB6gBmW+jYloKpG
JW4AoM0DPHRgUnbnTKSFD1JBVmBrAgbc
=mSu/
-----END PGP SIGNATURE-----
9:27 a.m.
New subject: Question on semanage fcontext -a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 semanage
>> fcontext -a to add a local filecontext definition, it is not used by
>> restorecon unless I specify the "-F" option. Without the
"-F" option,
>> 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
<current_context>-><new_context>
> This is probably because <current_context> is a customizable type like
> 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 types
> 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 users
now able to add local file contexts easily via semanage fcontext -a, it
isn't as necessary.
Yes I have in Rawhide, but if you are using an Older OS, those files are
still there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkfef8gACgkQrlYvE4MpobMIUgCeLkLGmqeGizf4Tgb/yy3wPhWM
RPEAn2Ol8SrzueD2p3w7g0M7gcjLUc9E
=bmbT
-----END PGP SIGNATURE-----
3:16 p.m.
New subject: Question on semanage fcontext -a
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
semanage
> > fcontext -a to add a local filecontext definition, it is not used
by
> > restorecon unless I specify the "-F" option. Without the
"-F"
option,
> > 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
<current_context>-><new_context>
>
> This is probably because <current_context> is a customizable type
like
> 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
types
> 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
users
now able to add local file contexts easily via semanage fcontext -a,
it
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
"/var/www/wikis/[^/]+/images"
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.
Now I use restorecon to relabel:
restorecon -vv /var/www/wikis/foo/images
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
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
system_u:object_r:httpd_sys_content_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0
Since both types are in the customizable_types file, why is one
automatically used, and the other only used when forced?
- Tim
--
Stephen Smalley
National Security Agency
4:30 p.m.
New subject: Question on semanage fcontext -a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
> semanage
>>> fcontext -a to add a local filecontext definition, it is not used
> by
>>> restorecon unless I specify the "-F" option. Without the
"-F"
> option,
>>> 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
> <current_context>-><new_context>
>> This is probably because <current_context> is a customizable type
> like
>> 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
> types
>> 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
> users
> now able to add local file contexts easily via semanage fcontext -a,
> it
> 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
"/var/www/wikis/[^/]+/images"
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.
Now I use restorecon to relabel:
restorecon -vv /var/www/wikis/foo/images
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
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
system_u:object_r:httpd_sys_content_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0
Since both types are in the customizable_types file, why is one
automatically used, and the other only used when forced?
- Tim
New Files/Directories adopt the context of their parent directry by
default. Unless the program is SELinux aware or a transition rule was
written in policy
dhcp_t creating files in directories labeled etc_t get a file context of
net_conf_t.
So since mkdir is not selinux aware and no policy rule has been defined,
you create the directory with the same context as the parent.
httpd_sys_content_t in both cases.
restorecon reads the file context file and assigns the correct context
after creation.
> --
> Stephen Smalley
> National Security Agency
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEUEARECAAYFAkfe4wUACgkQrlYvE4MpobM3SwCeIdXCI4G4d7zPyV0sop/sepRe
W8UAl21UT2Z2KpZPW/aFoO7Ft92UMaM=
=nXDO
-----END PGP SIGNATURE-----
8:45 a.m.
New subject: Question on semanage fcontext -a
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
> semanage
> > > fcontext -a to add a local filecontext definition, it is not used
> by
> > > restorecon unless I specify the "-F" option. Without the
"-F"
> option,
> > > 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
> <current_context>-><new_context>
> >
> > This is probably because <current_context> is a customizable type
> like
> > 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
> types
> > 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
> users
> now able to add local file contexts easily via semanage fcontext -a,
> it
> 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
"/var/www/wikis/[^/]+/images"
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
node), or
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
system_u:object_r:httpd_sys_content_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0
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
admin.
--
Stephen Smalley
National Security Agency
1:38 p.m.
New subject: Question on semanage fcontext -a
On Tue, 2008-03-18 at 09:45 -0400, Stephen Smalley wrote:
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
> > semanage
> > > > fcontext -a to add a local filecontext definition, it is not
used
> > by
> > > > restorecon unless I specify the "-F" option. Without the
"-F"
> > option,
> > > > 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
> > <current_context>-><new_context>
> > >
> > > This is probably because <current_context> is a customizable
type
> > like
> > > 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
> > types
> > > 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
> > users
> > now able to add local file contexts easily via semanage fcontext
-a,
> > it
> > 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
> "/var/www/wikis/[^/]+/images"
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
node), or
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
>
system_u:object_r:httpd_sys_content_t:s0->system_u:object_r:httpd_sys_script_rw_t:s0
>
> 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
admin.
Thanks. The feedback I've gotten has greatly clarified my understanding
of how SELinux labeling works.
- Tim
5881
days inactive
5885
days old
selinux@lists.fedoraproject.org
8 comments
4 participants
participants (4)
-
Daniel J Walsh -
Paul Howarth -
Stephen Smalley -
Taylor, Tim