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