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.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds