SELinux and Fedora [LWN.net]

SELinux and Fedora

Posted Jul 10, 2008 17:46 UTC (Thu) by dpquigl (subscriber, #52852) [Link]

I'll do my best to try and explain the problem here. For future reference a quick email to the
fedora-selinux, or NSA SELinux mailing lists will probably save you a lot of time and headache
and usually gets a quick reply.

The issue here is that a symlink is not the same as a directory. In the Linux DAC model
everything is treated the same. A file/directory/symlink etc.. all only have permissions based
on the traditional Unix permission bits. So there is no different between the file and a
symlink to the file because in the end the symlink will just resolve to that file anyway. In
SELinux we make a distinction between the many types of objects in the system. Files,
Directories, Sockets, Pipes, Symlinks, etc all are different and while some may share
permissions they aren't the same permission. So let's consider what happened in your case. The
policy says that postgres has the ability to look in a directory labeled a certain way and
read files labeled a certain way. All of a sudden what the program once thought was a
directory is now a symlink. Normally this isn't an issue because it will be resolved, however
chances are the link does not have the proper label and the policy isn't allowed to follow
symlinks of that type. For this reason SELinux blocks the access. You can probably imagine
several ways that symlinks can be used to trick postgres into doing something that wasn't
intended so this is a resonable security precaution.

There are two solutions to this problem.

1) Label the symlink correctly and if postgres isn't allowed to follow symlinks of that type
create a loadable policy module to allow it. This is a little more advanced for a regular user
and might be more than they are willing to do.

2) Bind mount the directory. Since bind mounts are just namespace manipulation even though the
directory is pointing somewhere else it is still a directory and it is still labeled with the
appropriate label. This is a much better solution since it won't require any policy
modifications.

In either of these steps it helps to add an entry using semanage for file_contexts to say that
the files under your new location keep a certain label on relabeling. This is normally taken
care of for you if everything is in the default location but since you have moved it if you
perform a system relabel it could steamroll your labels.

Hopefully this explained what was going on and will help you when you want to move things into
non-standard directories in the future. This and a bunch more information will eventually make
its way to selinuxproject.org

SELinux and Fedora

Posted Jul 10, 2008 18:22 UTC (Thu) by jwb (guest, #15467) [Link]

I think I speak for the average Linux user when I say:

What are you talking about?

Label?  Context?  These are not Unix concepts.  SELinux has secretly replaced my Unix system
with Folger's Crystals.  Let's see if anyone notices.

You say "You can probably imagine several ways that symlinks can be used to trick postgres
into doing something that wasn't intended."  Actually, I cannot think of any such thing.  Can
you perhaps explain to me how an adversarial symlink would have magically appeared in
/var/lib/pgsql under the traditional Unix security model?  Keep in mind that this directory is
owned drwx------ postgres postgres.

The question posed in the article was whether SELinux should be enabled by default.  If your
comment is any indication, SELinux is from another galaxy, and definitely should not be
enabled by default for people who were under the impression that they were using Linux.  If
there are customers who are insisting on this foreign access control system, then they are
probably smart enough to turn it on.

SELinux and Fedora

Posted Jul 10, 2008 19:36 UTC (Thu) by dpquigl (subscriber, #52852) [Link]

I think your statement is a little off. Also if you are a Linux sys admin with 10 years of
experience you aren't the average desktop user which is probably not doing what you are trying
to do.

These ideas have been in trusted Unixes for quite some time I think it is better to phrase
your statement as these aren't DAC concepts and I completely agree with you. You are thinking
of these things in terms of people who own it. MAC separates itself from DAC by saying we can
take all potential security relevant information into account when making a decision.

In the Unix DAC model you say this person owns this file. This group owns this file and this
is how this person and this group can interact with it. Even with ACLS it is the same but you
get more than user and group. MAC at least how it is implemented with SELinux says something
completely different. It says users aren't the ones performing actions because you aren't but
rather you invoke programs which perform actions.

An example of this is passwd. Since it access a privileged resource /etc/passwd it is marked
as a setuid application and is owned by root. The better thing to say here is what programs
should have access to that file and the answer is clear. passwd should have access to it and
programs that need to authenticate user credentials. Even then they should only be able to
read from it most of the time. This way if I have a compromised daemon running as root there
is no way for it to get access to my password file. This is because I didn't say that it is
root and can read everything root can but rather program foo has no right to read the password
file and send it somewhere.

So you are still thinking about this in terms of people ownership. In SELinux every process
and every object in the system are given a security context. A security context is the
security information associated with the object. In the case of SELinux there are several
parts to it but the most important is the type. This is what is mainly used to confine
applications and describe their behavior. The problem with DAC is an all or nothing mentality.

I am Dave. I am performing an action as Dave. My program does something malicious that I
didn't think it would do and has corrupted some files owned by Dave. The problem here is
everything was authenticated using Dave. The program which had no right touching certain
files which I didn't ask it to was able to corrupt them because they were owned by Dave so the
program could do whatever it wanted to any file as long as I owned it.

So back to SELinux now. There is no direct equivalent of this person owns this file. The
equivalent problem here in DAC is this. I've created a file I want a program to use. It is
owned by the complete wrong user. What is the solution? chown the file to the right user. In
SELinux terms this is I've created this file. I need this program to be able to access it.
However it has the wrong type what do I do? chcon the file to the appropriate type. Now you
can ask what is the appropriate type and that takes a bit of digging but it's possible to find
out.

To address your second paragraph upon looking at it this seems like a case of the policy being
a bit overly strict. In reality if you are able to read the contents of the directory that the
symlink is in and it inherits its security information from its parent you should probably be
able to follow it. But by no means should postgres be able to create that symlink.

To address your last paragraph I would not say it is from another galaxy. It is just a little
different. It may take a little bit of getting use to but it is immensely more powerful in
securing a system than DAC is. It just takes some time and a good book to understand. If you
want to take the time to learn SELinux (which is completely up to you) then I'd really suggest
reading Dan Walsh's blog and after briefly looking over the link posted in a latter comment
I'd say to look at that website as well. Both contain a lot of information about SELinux, how
it works, and what it accomplishes.

SELinux and Fedora

Posted Jul 11, 2008 10:49 UTC (Fri) by macc (subscriber, #510) [Link]

It does not KISS.

SE Linux introduces dependency on some person 
living inside SE Linux.

And it is not simple powerfullness as the 
original unix concept provides.

SE Linux is like german. You can build 
brilliantly convoluted sentences using 
a plethora of multisylable words but you 
are always in danger of loosing contact
to the tale you wanted to tell about.

SE Linux is not comparable to taking out
the airbags but more like the seat+belt-contacts
that prohibited starting the engine if 
a seated person was not secured by a seatbelt.

not good.

G!
MACC

SELinux and Fedora

Posted Jul 10, 2008 21:50 UTC (Thu) by Tet (subscriber, #5433) [Link]

Label? Context? These are not Unix concepts.

They are now. It's true that they weren't present in V7 Unix. But then again, neither were many of the other concepts we find in a modern day Unix. That's the nature of progress. Things change. It took me a long time before I was sold on SELinux, and my gut instinct was to turn it off, and run my machine with traditional Unix permissions. But just as I wouldn't dream of running a machine without a firewall in 2008, I now wouldn't dream of running one without SELinux. The landscape has changed, and Linux (and indeed, OSes in general) need to adapt. The benefits of running SELinux outweigh the initial pain it caused, and I believe Red Hat are 100% correct to have it turned on by default.