Head-banging targets, please

Fri Dec 31 01:03:40 UTC 2004

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 at 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 at 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