danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Share Next Entry
SELinux with cp/mv
danwalsh
Back in March 22nd, 2006, I wrote a blog on coreutils and SELinux . In that blog I had a couple of paragraphs on cp and the mv command.

mv

The mv command will attempt to maintain the security context of the file when it is moved to a different directory... This causes some
confusion, but this works the same was as with discretionary access. If I create a file owned by dwalsh in /tmp and then copy it to /etc, the ownership of the file will still be dwalsh in /etc. Similarly if the file was created in /tmp, it will have a security context of tmp_t, so when it is moved to /etc. It will continue to have tmp_t as it's security context.

cp

The cp command is a little different. If a file exists at you are copying over, the new file will maintain the file context of the previous file. So if I look at /etc/resolv.conf, I will see that it is labeled net_conf_t. If I copy a file over it say /tmp/resolv.conf, labeled tmp_t, onto /etc/resolv.conf, it will still be labeled net_conf_t. If I moved the file /tmp/resolv.conf onto /etc/resolv.conf, it will end up with tmp_t.

If the file does not exist it follow the rules defined above, IE it will either get the security context of the directory, or if a file_transition rule exists it will transition the context to follow the rule. So if you remove /etc/resolv.conf and cp /tmp/resolv.conf to /etc, you will end up with a security context of etc_t. Similarly if cp /etc/resolv.conf to ~/ it will end up with a security context of user_home_t. cp has an option to preserve the mode, ownership, and timestamps, but this option does not work with the file_context, you  need to use -Z.


UPDATE: We now have named file transitions in Fedora which for certain files/directory get labeled correctly on creation, so cp of a file named resolv.conf into a directory labeled etc_t will now get labeled net_conf_t atomically.

One of the problems we see quite often is a user creates an html file in his home dir or in /tmp and then moves it to /var/www/html. Apache then gets an access denied because apache is not allowed to read user_home_t. The quickest way to clean this up is with the restorecon command. The restorecon command reads the default file_contexts for the installed policy and then resets the file_context of all specified files.

restorecon /var/www/html/mypage.html


Sadly people continue to stumble on this.  Today I saw email from a user who was setting up a apache server and obviously mv'd content from his home dir to the  /var/www/html/updates directory.  I know this because the person attached a setroubleshoot message
Which showed the following alert.

Raw Audit Messages
type=AVC msg=audit(1343656110.659:126): avc:  denied  { open } for  pid=13506 comm="httpd" name="updates" dev="dm-1" ino=278541 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir


Notice the open access, from httpd to the updates dir.  I figure the admin mv'd it from his home directory since the content is labeled with he user_home_t type. SELinux is complaining because from its point of view, the web server is trying to read content in the users homedir. This users homedir might contain credit card information, tax returns, password etc, stuff we would want to block a hacked web site from accessing.    I am pretty sure the user went in an changed the discretionary ownership/permissions, since the apache user would not be allowed to read a directory owned by the user with the default permissions on a directory created in his homedir.
After fixing these permissions he did not think about SELinux and tried to run apache and got permission denied.  Luckily the setroubleshoot tool was installed and the user got an alert that said.

SELinux is preventing /usr/sbin/httpd from open access on the directory /var/www/html/updates.

*****  Plugin restorecon (99.5 confidence) suggests  *************************

If you want to fix the label.
/var/www/html/updates default label should be httpd_sys_content_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/www/html/updates


If you create content in your home dir to be used  by a service, it is always a good idea to check all the security attributes of the content after you cp/mv it in place.  restorecon is often the correct tool to use.  And please read the alerts...

For more information on SELinux and apache, you can read the apache_selinux man page.

man apache_selinux

No HTML allowed in subject

  
 
   
 

(will be screened)

You are viewing danwalsh