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.
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. 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? 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. 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. 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. 5) Does it make sense to have a Workstation installation with the "strict" policy? Under what circumstances?
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.
Thanks for the help.
On Thu, 30 Dec 2004 16:26:24 -0600, David Hart wrote:
I need help understanding SELinux!
Me too! But I seem to be a bit further along, so I'll see if I can help.
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.
Yes it is unfortunate that the documentation ages so quickly, but this is I think unavoidable. SELinux is still quite a new technology and has a lot of maturing to do.
It also doesn't help that Fedora have patched upstream SElinux extensively in the process of actually making it usable, for instance they've made a lot of stuff more automatic. I believe these patches are being folded back in upstream, but the problem with doing it "upside down" like this is that the official docs which most people find first do not correspond to an actual FC3 installation, which is what most people are actually playing with SELinux on.
I do not know why these patches weren't developed upstream then pulled down as they became ready. I guess there are good reasons.
And, the answers to some basic questions:
- 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.
They're quite large and not needed for SELinux to function. It's unfortunate that the docs assume it's installed, but it's quite a common mistake (eg instructions that tell you to compile software assuming the dev tools are installed, very common Linux newbie mistake).
- 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?
I don't think they are required. On Fedora I think the standard commands like su etc were patched to use SELinux automatically, so a standard "useradd" should do the trick.
- 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.
If you mean where AVCs are logged that'd be /var/log/messages.
- 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.
Here is one from mine:
Dec 30 22:40:39 littlegreen kernel: audit(1104446439.698:0): avc: denied { search } for pid=4659 exe=/sbin/ldconfig name=lib dev=hdd2 ino=4244688 scontext=user_u:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir
You can get the same error by creating a directory eg ~/.local/lib, dropping a library in there then running:
/sbin/ldconfig -n .
which should create some magic symlinks for the linker to use, but with policy as of December 30th 2004 this generates an AVC.
- Does it make sense to have a Workstation installation with the "strict" policy? Under what circumstances?
Probably not. Strict seems to be under heavy development still. There seem to be issues with targetted policy still judging by the above test! That ldconfig command should not have failed.
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.
For now I think it's best to ignore SELinux and assume it'll work in the background, even if sometimes it doesn't for whatever reason. You need to know about SELinux for effective system administration, or will in future, and perhaps also for software development. But regular users should be able to ignore it and just enjoy the benefits.
thanks -mike
On Friday 31 December 2004 09:43, Mike Hearn mike@navi.cx wrote:
It also doesn't help that Fedora have patched upstream SElinux extensively in the process of actually making it usable, for instance they've made a lot of stuff more automatic. I believe these patches are being folded back in upstream, but the problem with doing it "upside down" like this is that the official docs which most people find first do not correspond to an actual FC3 installation, which is what most people are actually playing with SELinux on.
I do not know why these patches weren't developed upstream then pulled down as they became ready. I guess there are good reasons.
The patches are developed by the people who have the time and skills necessary. Some of those people are Red Hat employees (including me). Code that is developed by Red Hat employees generally goes into Red Hat first before going upstream.
But that isn't the reason that the documentation lags behind development. The reason is that a lot of work is being done on developing the code and policy, but little time is available for documentation. I think that things are improving in this regard, but there is a lot of documentation work to be done.
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:
- 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.
- 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.
- 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.
- 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. :)
- 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
On Thu, 2004-12-30 at 20:03, Karsten Wade wrote:
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.
By default, SELinux (via the kernel audit framework) logs using the normal kernel logging facility, i.e. kernel -> klogd -> syslogd, and then syslogd dispatches based on /etc/syslog.conf, typically to /var/log/messages. However, the kernel audit framework will instead dispatch the audit messages to an audit daemon if one is present; work on an audit daemon is ongoing - see the linux-audit mailing list.
However, the kernel audit framework will instead dispatch the audit messages to an audit daemon if one is present;
This is good to know. I am working on the audit daemon and noticed that avc messages usually wind up in syslog *even if* the audit daemon is running. I see "real" audit messages going to /var/log/audit.log and scrolling dbus avc messages in /var/log/messages both at the same time.
Not sure how the kernel decides where to send each of these...but they do go to different places on my machine.
-Steve Grubb
__________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
On Mon, 2005-01-03 at 11:52, Steve G wrote:
This is good to know. I am working on the audit daemon and noticed that avc messages usually wind up in syslog *even if* the audit daemon is running. I see "real" audit messages going to /var/log/audit.log and scrolling dbus avc messages in /var/log/messages both at the same time.
Not sure how the kernel decides where to send each of these...but they do go to different places on my machine.
dbusd avc audit messages are generated by libselinux using a callback function provided by dbusd, and dbusd likely is just using syslog() rather than communicating with the audit daemon. The kernel audit framework isn't involved in that path. You'll need to change the callback function provided by dbusd to instead send an AUDIT_USER message with the audit data (or alternatively, have it talk directly to the audit daemon).
For the kernel, the relevant code is audit_log_drain() in kernel/audit.c. That checks whether audit_pid has been set, and if so, it sends the audit message to that process; otherwise, it ends up calling printk to send via klogd.
dbusd avc audit messages are generated by libselinux using a callback function provided by dbusd, and dbusd likely is just using syslog() rather than communicating with the audit daemon.
I traced through the code and created a patch for dbus to use libaudit. It now works fine. But, I noticed the kernel generated messages have more information in them. I guess that's what the audit hook (avc_func_audit) was for.
-Steve Grubb
__________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
On Tue, 2005-01-04 at 09:42, Steve G wrote:
I traced through the code and created a patch for dbus to use libaudit. It now works fine. But, I noticed the kernel generated messages have more information in them. I guess that's what the audit hook (avc_func_audit) was for.
I'd suggest coordinating with Colin, as he knows the dbus SELinux code well. Yes, the libselinux AVC constructs a buffer containing the information it knows plus any supplementary information provided by the audit callback (e.g. information known only to the caller, in this case dbusd) and then calls the log callback with the resulting buffer.
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.
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.
Have you read "NSA's Open Source Security Enhanced Linux" By O'reilly? http://www.oreilly.com/catalog/selinux/
I have the E-book and you can find it on google with little trouble. Someone was suppose to get it for me for Christmas, but low and behold.. socks!
I did buy this book and was wondering what the Fedora Developers thought abou it compared to how Fedora is currently using/intergrated SELinux? Is this book fairly accurate to the same methods used?
On Thu, 30 Dec 2004 20:25:40 -0800, Vincent uproot@sbcglobal.net wrote:
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.
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.
Have you read "NSA's Open Source Security Enhanced Linux" By O'reilly? http://www.oreilly.com/catalog/selinux/
I have the E-book and you can find it on google with little trouble. Someone was suppose to get it for me for Christmas, but low and behold.. socks!
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org
-
David P. Hart -
Justin Conover -
Karsten Wade -
Mike Hearn -
Russell Coker -
Stephen Smalley -
Steve G -
Vincent