Any ways back to SELinux for Dummies.
SELinux has a few commands for managing file context.
ls -Z is the tool to use when viewing file context.
> ls -lZ /tmp/dan
-rw-rw-r-- dwalsh dwalsh user_u:object_r:user_home_t /tmp/dan
You can also use getfattr although, you need to specify -n security.selinux
> getfattr -n security.selinux /tmp/dan
getfattr: Removing leading '/' from absolute path names
# file: tmp/dan
security.selinux="user_u:object_r:user_h
There are multiple commands for setting file labels. Remember while all of these tools can modify file context, the kernel policy will determine whether you are able to run the tools and whether you are able to modify the file context.
- chcon
- setfiles
When I started working on SELinux, I hated the way setfiles worked, because every time I wanted to relabel a single file I would have to enter this huge path to where the system file_context was stored. So I decided to make a new tool called restorecon. I probably screwed up in that I didn't rewrite setfiles to make it work like restorecon, but I didn't.
- restorecon
After working with restorecon for a while, I realized there was a lot of scripts I was generating to do some neat things to fix file context on the system. Some of these things would have been difficult to do in "C" so I built a wrapper around restorecon/setfiles called
fixfiles.
- fixfiles
- matchpathcon
Finally, if you recursively walk a directory tree with setfiles and restorecon, they use the "C" function ntfw. One problem with this function is that there is no way to tell it to stop recursively walking this branch of the tree, but continue on others. You either continue or fail completely. So even if you are walking a tree and discover you have stepped into a file system that does not support extended attributes, you will either need to continue or fail altogether. So if you say something like restorecon -R -v / and it steps into a NFS file system it will continue through out this file system checking every file to find out they do not support xattrs. This has caused problems in the past in that it can take a very long time. the find command has a -prune call which fixes this problem. So now fixfiles uses "find" to walk the tree and then hands restorecon the list of files to relabel. I believe that we could rewrite setfiles/restorecon to use fts, to work in a similar way. I have this towards the end of my todo list, but if anyone has spare cycles, this would be a nice feature...
Tomorrow I will talk about the new daemon restorecond.
Dan
2006-04-06 12:41 pm (UTC)
Your site has helped me understand more about SELINUX than I ever did before, and I appreciate your generosity.
I've been using Fedora since Core 3 for servers, running Postgresql databases for a tcp application. Core 3 was pretty solid, and Core 4 was okay; however, Core 5 has been an uphill climb.
I installed Core 5 on a new machine with Postgresql, sendmail, PHP - straight from the Fedora Core 5 DVD. The install goes well. I take my dumped postgresql database from the Core 4 machine, import into the new database of the Core 5 (according to the instructions from the Fedora site), reboot, and Postgresql fails to launch on boot up. Yesterday, I followed your links about using audit2allow and semodule in an effort to fix it, but the problem would not go away.
Thinking I'd erred somehow, I started with a fresh install early this morning, restored the database, rebooted, and the same messages appear in /var/log/messages:
Apr 6 07:56:21 vsi kernel: audit(1144324578.867:2): avc: denied { append } for pid=1816 comm="hostname" name="pgstartup.log" dev=dm-0 ino=14534786 scontext=system_u:system_r:hostname_t:s0 tcontext=system_u:object_r:postgresql_lo
Apr 6 07:56:21 vsi kernel: audit(1144324579.263:3): avc: denied { search } for pid=1830 comm="postmaster" name="pgsql" dev=dm-0 ino=5466913 scontext=system_u:system_r:postgresql_t:s
In my pgstartup log:
postmaster cannot access the server configuration file "/data/pgsql/postgresql.conf": Permission denied
I don't get it, because the permissions are correct. Is this a bug with the new SELINUX?