On Thu, 2004-12-30 at 16:26 -0600, David Hart wrote: > I need help understanding SELinux! > > I've read just about every on-line SELinux article I can find, and I am > getting progressively more confused as I read more. Following along in > these articles on a Fedora Core 3 system, reading documents written for > Fedora Core 2 Test 3 and before, is confusing. The older the document, > the more my installation fails to match the documentation. The Fedora docs project needs writers and content. While the FAQ is (relatively) up-to-date for FC3, we need more HOWTO documentation. If you know any writers who want to tackle SELinux tutorials, send them over to fedora-docs-list, I'll do what I can to get them started. > I need a starting place, some things to look at once I have my Fedora > Core 3 installation running. Some simple things, some that work > correctly, some that fail and I can learn how to track down and fix. > > And, the answers to some basic questions: > 1) Why does a Fedora Core 3 installation, with SELinux "Active" or > "Warn", not install selinux-policy-targeted-sources? I kept > pulling my hair out (little that there is) when trying to find: > /etc/selinux/targeted/src/policy > All the documents referred to this directory, and it was VERY > confusing not to find it. This directory should at least be > an empty directory after a fresh install. In the first "Tip" near the top of http://fedora.redhat.com/docs/selinux-faq-fc3/ is a link to a pre-filled "bugzilla template". Use that to fill out a bug, severity: Feature. I'll then include this question in the FAQ. To answer you, there are several reasons for the policy source not being installed by default: * As with the rest of Fedora Core, SELinux needs to be able to run with just a binary policy present and no source installed. This is why they are separate packages. * Updating the policy does different things depending on if you have the source installed. If you have only the binary policy, i.e., the default supported environment, you only have to update the binary policy at /etc/selinux/targeted/policy/policy.version. If you have the policy source installed, it may be because you are customizing the policy, and rpm needs to be careful not to clobber you changes. Others can contribute further reasons. > 2) Are the setools and setools-gui packages required to be used on a > SELinux enabled system? If so, why are they not installed when > SELinux is installed? In particular, I am very confused about how > to create new users and new groups. It looks like I need to update > our in-house instructions to use seuseradd, seuserdel, etc. instead > of useradd and userdel? You do not, unless you plan on customizing policy to divide users to be controlled by SELinux. SELinux maintains its own set of users, e.g., all untrusted users are part of user_u. Under the targeted policy, aiui the user is generally not controlled. > 3) Where the heck is the SELinux audit file? Try as much as I could, > I can't find it. Every document references it, but none I have > found actually refer to it by path/filename. aiui, this is just /var/log/messages. Flask is a framework, and the documentation tends to be vague about particulars like where you choose to put audit logs. SELinux, the implementation of Flask, generally uses /var/log/messages, but I'm sure even that could be different if you wanted. > 4) I know you guys discuss policy problems all the time, from the > viewpoint of their AVC log events, but I'd like to see what one of > these AVC log events looks like on my system. In particular, I > have a Fedora Core 3 Workstation installation running the targeted > policy in enforcing mode. I'd appreciate a simple test I could > perform that would generate an AVC log entry, some idea on how to > look for the log entry, and some idea about how to analyze the log > entry. This should work with a default targeted policy: 1. In one terminal, 'su - root' and 'tail -f /var/log/messages' 2. In another term, as a normal user, type 'chcon -t unlabeled_t /etc/httpd/conf/httpd.conf' -- this is trying to change the file context of httpd.conf, specifically the type attribute. You should get an error such as: [auser@urania ~]$ chcon -t unlabeled_t /etc/httpd/conf/httpd.conf chcon: failed to change context of /etc/httpd/conf/httpd.conf to system_u:object_r:unlabeled_t: Operation not permitted 3. You'll notice that no error is generated in /var/log/messages. This is because normal UNIX security has intercepted the command; normal user permissions has blocked the user from writing to the file attributes. SELinux is not reached, so no AVC error is generated. 4. In the second term, 'su - root' and 'chcon -t unlabeled_t /etc/httpd/conf/httpd.conf'. You should get an error such as: [root@urania policy]# chcon -t unlabeled_t /etc/httpd/conf/httpd.conf chcon: failed to change context of /etc/httpd/conf/httpd.conf to system_u:object_r:unlabeled_t: Permission denied Note the permission denied -- UNIX ownership said it was OK to change this file, but SELinux rules said no. 5. Look in the log and you will see this denial message: Dec 30 15:01:40 urania kernel: audit(1104447700.246:0): avc: denied { associate } for pid=26444 exe=/usr/bin/chcon name=httpd.conf dev=dm-0 ino=1018443 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:fs_t tclass=filesystem * The action denied is an "associate", i.e., trying to associate a new file attribute with the target file. * The process is exe=/usr/bin/chcon * The file acted upon (object) is name=httpd.conf at ino=1018443 (sometimes it's useful to have the inode). * The source context scontext=system_u:object_r:unlabeled_t is trying to be associated with a target context tcontext=system_u:object_r:fs_t. fs_t is the default type for conventional file systems. AIUI, the policy does not allow a user to change the type of a file on the file system to unlabeled_t. The denial is happening at the file system level before getting to the file itself. [This is where someone with more understanding of the policy specifics steps in with the final detail ;-) ] The reason I picked httpd.conf is that it is a file that the user is denied UNIX permissions, but root should be able to manipulate. > I know, blasphemy. But there are three ways that adults > learn: > 1. Visual: people who learn by seeing it done. > 2. Auditory: people who learn by hearing. > 3. Kenesthetic: people who learn by doing (touch and body > movement). > I'm a #3. In a freeform, off-topic discussion, I'd posit more than three. :) > 5) Does it make sense to have a Workstation installation with the > "strict" policy? Under what circumstances? I can think of usage scenarios. 1. Kiosks 2. Library Web browser machines 3. Specific lab usages The first two seem reasonable right now, based on my understanding of the policy for Mozilla et al. In fact, strict policy will likely just work for a machine dedicated to Web browsing, email, and light office productivity. YMMV. :) The third would require a tight requirement spec and work to customize the policy, I'd reckon. > I am putting instructions together for people in my Lab on how to > install and use Fedora Core 3. One of the early lessons I want to > document is some simple instructions on how to use SELinux. Then, as > other instructions are written for other Lab-oriented tasks, I would > integrate SELinux into these instructions. The people in the Lab are > responsible for maintaining their various computers, so knowledge about > SELinux appears necessary. If I can't understand it and explain it to > them, things are going to get messy. There is not much they should bump up against. Said as a user of FC3 with SELinux. If you want to have them serve content from ~/public_html, you may need to educate them on using 'chcon' to fix the labels on files they put in there. If you want to have them execute their own Web scripts, you can likely configure it so that it mainly works from their standpoint. - Karsten -- Karsten Wade, RHCE, Sr. Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
