When I first started working on SELinux over 10 years ago, one of the first packages I worked on was coreutils. We were adding SELinux support to insure proper handling of labeling. After that we did not touch it for several years.
Last year, I decided to investigate if I could improve coreutils handling of labels on initial content creation. Well it took a while but my patches were finally accepted, with lots of fixes from the upstream, and coreutils-8.22 just showed up today in Rawhide.
I am very excited about this release. I believe it can allow Administrators to fix one of the biggest problems users have with SELinux, objects getting created with the incorrect context.
My patches basically standardized "-Z" with no options to indicate you wanted the target directory to get the "default" label.
# touch /tmp/foobar
# mv /tmp/foobar /etc
# ls -lZ /etc/foobar
# -rw-r--r--. root root staff_u:object_r:user_tmp_t:s0 /etc/foobar
As opposed to:
# touch /tmp/foobar
# mv -Z /tmp/foobar /etc
# ls -lZ /etc/foobar
# -rw-r--r--. root root staff_u:object_r:etc_t:s0 /etc/foobar
The traditional use of a command like mv was to maintain the "Security" of an object you are moving. mv command would maintain the ownership, permissions, and SELinux Labels. The problem with this is users/administrators would not expect this, by adding the "-Z" to the mv command, the administrator guarantees that the object will get he correct label based on the destination path, which over the years, I believe is what the administrator would expect. The "-Z" option in coreutils now indicates the equivalent of running restorecon on the target, except in most cases the label is correct on creation of the content.
"mv -Z /tmp/foobar /etc/foobar" == "mv /tmp/foobar /etc/foobar; restorecon /tmp/foobar"
One of the reasons we did not do this sooner, was the speed of reading in the labeling database. The latest SELinux toolchain loads the labeling database in a fraction of the previous time, allowing us to make these changes.
Setting up coreutils alias
I would even suggest that it would be a good idea to alias
alias mv='mv -Z'
for most users.
A common mistake is to mv content around in the homedir. A mistake I have made in the past was to an html file to a my account on people.fedoraproject.org and then to ssh into the machine and then mv it to the public_html directory. ~/public_html is labeled httpd_user_content_t which is readable by default from the apache server, while the default label of my homedir is not, user_home_t.
mv ~/content.html ~/public_html/
This command would end up with the ~/public_html/content.html being labeled user_home_t, and the page would not show up on the web site. Users would not know why, and would probably not no about SELinux. But if the admistrator changed the alias for the mv command, everything would just work.
Similarly the -Z option has been implemented for all of the commands that create content in coreutils.
mknod -Z, mkdir -Z, mkfifo -Z, install -Z
Currently in init scripts we have lots of code that does; \
mkdir /run/myapp; restorecon /run/myapp
Which can be replaced with
mkdir -Z /run/myapp
What about Disabled Machines, or machines that do not support SELinux?
On an SELinux disabled system, the -Z option will be ignored.
Getting the Label correct at file creation has been improved greatly in the current Fedora's with the introduction of file name transitions. Fixing coreutils to allow administrators to change the default of standard tools to set default labels on object creation is nice.
alias mv='mv -iZ'
alias cp='cp -iZ'
alias mkdir='mkdir -Z"
alias mknod='mknod -Z"
alias install='install -Z"
I hope to get this new coreutils backported into RHEL7...
One thing to remember about this from a security point of view. A calling confined domain would still be prevented from creating content with the default label, if it was not allowed by SELinux policy to create content with that label. The change to coreutils, just allows the process to attempt to create the content with the correct label.
Thanks to coreutils upstream for working on these patches with us.