- Notice about file move
When you move file to another directory by mv command, you have to use restorecon
command. Like below.
* Example: Upload homepage
# pwd
/root/homepage/index.html
# mv index.html /var/www/html
# restorecon -R /var/www/html
If you forget last restorecon command, Apache will not be able to
access /var/www/html/index.html, even if allow /var/www/** is
described for httpd_t.sp.
This is because, access right is inherited from source file in mv command.
In this example, httpd_t domain can not access under /root, but can
read under /var/www. After mv command, access rights to
/var/www/html/index.html is the same as
/root/homepage/index.html.
To fix this situation you have to use restorecon command.
GUI policy generator sometimes suggests restorecon.
- File creation
Newly created file inherits access rights from directory. See
example below.
Assume following configuration exists.
domain foo_t;
allow /foo/bar/** r,s;
allow /foo/bar/test.txt r,w,s;
foo_t can read files under /foo/bar, and write /foo/bar/test.txt.
If /foo/bar/test.txt does not exist at the time of configuration,
and after configuration /foo/bar/test.txt is created, foo_t can read test.txt, because newly created test.txt inherits allow
/foo/bar/**. This is confusing, but limitation of our
implementation.
To fix this, you have to do
restorecon -R /foo/bar
Then foo_t can read/write test.txt.
- Why restorecon is necessary?
SELinux internally identifies resources by label called type.
When mv command, label is preserved.When file is newly created,
type is inherited from belonging directory.
We have to fix relationship between file and type by restorecon command.
- cron jobs
Cron jobs are not confined. If you want to protect cron job,
edit system_crond_t.sp, delete allowpriv all;. However,
configuring cron jobs correctly will be very difficult.
- Dynamically created/deleted files
For files that are dynamically created/deleted, access control
sometimes do not work well.
See example below.
domain foo_t;
allow /foo/bar/** r,s;
allow /foo/bar/test.txt r,w,s;
In this, if test.txt is deleted, and created, test.txt inherits access
right of directory.
So, foo_t can read test.txt but can not write test.txt.
You can fix by restorecon, but when it is re-created, you have to do
restorecon again..
Therefore, for files whose access right is different from directory, and they
are deleted/created, access control does not work well.
To resolve this, you have following solutions.
- Give up controlling access for individual files
you can write
allow /foo/var/** r,s,w.
By configuring above, if test.txt is deleted and created, foo_t can
write test.txt, however foo_t can write other files under
/foo/bar directory.
- Use allowtmp
To protect such temporally files, SPDL supports allowtmp
statement.
You can configure like following.
allowtmp /foo/bar -name auto r,w,s;
By allowtmp statement, file can be identified by label in SPDL.
This allowtmp statement means, files created under /foo/bar is
labeled as foo_foo_bar_t(-name auto generates label name based
on domain and directory name, foo_t + /foo/bar = foo_foo_bar_t).
And foo_t can read, write files that have foo_foo_bar_t label.
By above, when test.txt is deleted and created again, test.txt
is given label(foo_foo_bar_t) and identified by label.
In allowtmp, file type transition in SELinux is internally used.
If you want to access test.txt from other domain, you have to
specify label not filename, like below.
allow foo_foo_bar_t r;
In default policy,allowtmp is used to control access to /etc/mtab and temporally
files under /tmp, /var/tmp.
- Device files other than /dev
Devices have critical impact to security, so it is treated specially.
In default policy, device is assumed to exist under /dev.
If you write allow statement for devices other than /dev
directory, you can not access it.
If you want to access devices other than /dev, you have to write
allowdev statement.
If you want to read access devices in /var/chroot/dev/null,
you have to write following, before describing allow /var/chroot/dev/null.
allowdev -root /var/chroot/dev;
- Symbolic link
Configuration to file that contains symbolic link is ignored.
For example,
allow /etc/init.d/httpd r;
is ignored(init.d is symbolic link to rc.d/init.d).
- Hardlink
In Linux system, contents of file can be refereed by multiple name
using hard link. Hardlink is rarely used recent distro, but you
have to note about this if you want to preserve security.
In SPDL, following rule exists about hard link.
If file has multiple hardlink, to access the file, you must
specify originally existing file name. Other file names are ignored
For example, /etc/shadow and /var/chroot/etc/shadow is hardlinked,
and /etc/shadow exists originally, to access contents of
/etc/shadow, you have to use file name /etc/shadow. Configuration
using /var/chroot/etc/shadow will be ignored.
If some domain(assume foo_t ) want to read
/var/chroot/etc/shadow, you have to configure allow
/etc/shadow r;
Next, there is a question, what is criteria of file name originally exist? Following is answer.
In following, /etc/shadow and /var/shadow is assumed as
hardlinked files.
- If rule is described to one file name, the file name is treated as
original.
Ex: allow /etc/shadow r; is described in some domain, but
rules using filename /var/shadow is not described,
/etc/shadow is treated as original.
- If rules are described to multiple hardlinked file name, the
filename that name is the youngest is treated as
original
Ex: allow /etc/shadow r, and allow /var/shadow r; are
described in some domains, /etc/shadow is treated as
original, because /var/shadow 
/etc/shadow.
- If rules are not described for hardlinked files, the
directory names that hardlinks exist are compared. The
file whose directory name is oldest is original.
Ex: /etc/shadow, /var/shadow do not appear in any domain.
Then /var/shadow is treated as original. Because
/var /etc.
If you are not sure which hardlink is original, you can
use all names. It means, you can describe
allow /etc/shadow r;
allow /var/shadow r;
1 of 2 will be ignored, and do no harm.
Above treatment of hardlink is necessary to avoid a kind of back door
of path name based configuration. Assume hard link to
/etc/shadow is created by some trick under /var/www/html, without this
behavior, Apache web server can access contents of /etc/shadow
via /var/www/html/shadow. To protect this, we must limit way to access
hard link to 1.
http://securityblog.org/brindle/2006/04/19 is good reference.
