SELinux, F8, and httpd

[Nathan Grennan]

  How do I disable SELinux completely for httpd? In F7 from what I have 
read it was "setsebool -P httpd_disable_trans 1". I get the errors below 
when I try that. I looked in the policy files and couldn't find any 
reference of it. I looked in system-config-selinux, and only found 
options to tweak small aspects of SELinux for httpd, but not completely 
disable it. I also notice there doesn't seem to be options to disable 
selinux for any service. Not having a per service disable option means 
your only recourse in some situations is simply to put SELinux in 
permissive mode.

libsemanage.dbase_llist_set: record not found in the database
libsemanage.dbase_llist_set: could not set record value
Could not change boolean httpd_disable_trans
Could not change policy booleans


  I want to disable httpd, because I don't want to have to run 
restorecon ~/public_html/dir if I move a directory from ~/ to 
~/public_html. I find the whole idea of restorecon funny. It isn't like 
chown or chmod where you give it options telling it what to change it 
to. It is just supposed to fall back on policy. So why not just have the 
system automatically set the default policy on the move? You can say, 
but there is chcon, but even if you use it to hand set something, if you 
restorecon or relabel on boot are have used in the future it is likely 
going to wipe any changes made with chcon.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nathan Grennan wrote:
>   How do I disable SELinux completely for httpd? In F7 from what I
> have
>  read it was "setsebool -P httpd_disable_trans 1". I get the errors below
>  when I try that. I looked in the policy files and couldn't find any
>  reference of it. I looked in system-config-selinux, and only found
>  options to tweak small aspects of SELinux for httpd, but not completely
>  disable it. I also notice there doesn't seem to be options to disable
>  selinux for any service. Not having a per service disable option means
>  your only recourse in some situations is simply to put SELinux in
>  permissive mode.
>  
>  libsemanage.dbase_llist_set: record not found in the database
>  libsemanage.dbase_llist_set: could not set record value
>  Could not change boolean httpd_disable_trans
>  Could not change policy booleans
>  
>  
>   I want to disable httpd, because I don't want to have to run restorecon
>  ~/public_html/dir if I move a directory from ~/ to ~/public_html. I find
>  the whole idea of restorecon funny. It isn't like chown or chmod where
>  you give it options telling it what to change it to. It is just supposed
>  to fall back on policy. So why not just have the system automatically
>  set the default policy on the move? You can say, but there is chcon, but
>  even if you use it to hand set something, if you restorecon or relabel
>  on boot are have used in the future it is likely going to wipe any
>  changes made with chcon. 
chcon is just like chown or chmod, and actually change a
file context to
httpd_sys_content_t will survive a relabel, which you really should not
need to do.  If you cp the contents of the directory they should adopt
the context of the destination directory. Also you could use restorecond
to watch for the creation of files in the directory.

*_disable_trans was removed because it caused as many problems as it
solved.  When you disable trans on one domain, you can cause other
domains to to blow up because file context gets screwed up.

If you really want to disable trans you could change the context of
httpd to bin_t.   chcon -t bin_t /usr/sbin/httpd, but this will not
survive a relabel.  We are hoping to add permissive domains pretty soon,
where you define httpd as a permissive domain, and it would only report
access problems and not enforce them.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkfGLhcACgkQrlYvE4MpobPi5gCgh0FGd8wRkSwZyGo5omA+6k7U
> KTUAn3/a5d4jY187Dmpwf1vrFWtE2pFe
> =1s8G
> -----END PGP SIGNATURE-----

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nathan Grennan wrote:
>  Daniel J Walsh wrote:
> > chcon is just like chown or chmod, and actually change a file context to
> > httpd_sys_content_t will survive a relabel, which you really should not
> > need to do.  If you cp the contents of the directory they should adopt
> > the context of the destination directory. Also you could use restorecond
> > to watch for the creation of files in the directory.
> >
> >   
>  Would other contexts survive though? httpd_sys_content_t is really here
>  nor there in that situation, because it is the default policy.
>  
>  So I could custom configure restorecond, but why does it even have to be
>  a daemon. Why couldn't the kernel just to it automatically during the move?
Well the kernel knows nothing about file paths.  The real problem is the
semantics of the mv command.  The mv command maintains the file context
of the source.  So if you mv from user_home_t into httpd_sys_content_t
it will stay user_home_t.  cp on the other hand adopts the context of
the destination by default.  This mirrors the way DAC permissions work.

The problem is people understand and have experienced DAC permissions.
So when apache can't read a file you check the ownership and the
permissions, but with MAC/SELinux you also need to check the file context.
> > *_disable_trans was removed because it caused as many problems as
> it
> > solved.  When you disable trans on one domain, you can cause other
> > domains to to blow up because file context gets screwed up.
> >   
>  This makes sense.
> > If you really want to disable trans you could change the context of
> > httpd to bin_t.   chcon -t bin_t /usr/sbin/httpd, but this will not
> > survive a relabel.  We are hoping to add permissive domains pretty soon,
> > where you define httpd as a permissive domain, and it would only report
> > access problems and not enforce them.
> > 
httpd_* context does survive relabels but it is always better to use
semanage fcontext -a ...
To manipulate the systems default labeling.

>   That it wouldn't survive a relabel makes it pretty worthless.
>  
Well you really should not be relabeling regularly (You should Never
need to).  Although an update to policy could relabel the /usr/bin/httpd
file on you.

>   I was thinking about permissive domains when I was writing the
> original
>  e-mail. Good to hear it is being worked on. 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkfGQfUACgkQrlYvE4MpobO2qQCgn6N+PhvYhMmagyF7NV4t9w3+
> 7L8AnRo8B0xpjAhzErxs/roaIlMezYrQ
> =WLDM
> -----END PGP SIGNATURE-----

[Nathan Grennan]

Daniel J Walsh wrote:
>  chcon is just like chown or chmod, and actually change a file context
> to
>  httpd_sys_content_t will survive a relabel, which you really should not
>  need to do.  If you cp the contents of the directory they should adopt
>  the context of the destination directory. Also you could use restorecond
>  to watch for the creation of files in the directory.
>
>     
Would other contexts survive though? httpd_sys_content_t is really here 
nor there in that situation, because it is the default policy.

So I could custom configure restorecond, but why does it even have to be 
a daemon. Why couldn't the kernel just to it automatically during the move?
>  *_disable_trans was removed because it caused as many problems as it
>  solved.  When you disable trans on one domain, you can cause other
>  domains to to blow up because file context gets screwed up.
>     
This makes sense.
>  If you really want to disable trans you could change the context of
>  httpd to bin_t.   chcon -t bin_t /usr/sbin/httpd, but this will not
>  survive a relabel.  We are hoping to add permissive domains pretty soon,
>  where you define httpd as a permissive domain, and it would only report
>  access problems and not enforce them.
>     
  That it wouldn't survive a relabel makes it pretty worthless.

  I was thinking about permissive domains when I was writing the 
original e-mail. Good to hear it is being worked on.