Linux security non-modules and AppArmor [LWN.net]

Linux security non-modules and AppArmor

Posted Jun 28, 2007 5:28 UTC (Thu) by dlang (✭ supporter ✭, #313)
In reply to: Linux security non-modules and AppArmor by jamesm
Parent article: Linux security non-modules and AppArmor

that's a good restatement of the SELinux pitch. A shorter version is that SELinux can do everything and nothing else is needed.

except that the SELinux framework cannot reasonably implement the AppArmor semantics since a simple rename could require the relabeling of thousands of files before the system works properly.

and no, I don't buy the answer from the SELinux camp of "well, don't do that then" as being reasonable

for the record I am not a current user of AA, however I definantly see it as being useful and would start useing it within a couple of months of it being included.

the arguments against keeping the LSM modular all assume a SELinux approach of tagging everything and worry about how to tag things on module insertion and what to do with the tags on module removal.

if you look at other possible modules the answers are much clearer.

for example, with App Armor when you unload the module everything is unconstrained. when you load a module all future accesses are checked (if the name of the program being run can only be found at execution time then it could only constrain programs executed after it's loaded, which could be an advantage under some conditions)

another LSM I ran across recently allowed you to limit network use by programs. it also seems like the load/unload events would be clear (or at least straightforward)

(Log in to post comments)

Linux security non-modules and AppArmor

Posted Jun 28, 2007 10:15 UTC (Thu) by mingo (subscriber, #31122) [Link]

Note that you did not actually answer to the essence of James' arguments.

it boils down to: the architecture of SELinux is there for a reason (and it is well documented), and the answer is not to ignore it and remove the "extra complexity" out of ignorance, but to understand the security issues behind them and provide an alternative solution (if you can).

You are in essence putting a chair into the fire-proof door to keep it open permanently, just because you find it inconvenient. Instead of designing an automatic fire-proof door that opens automatically when a human (with the right permission) approaches.

Linux security non-modules and AppArmor

Posted Jun 28, 2007 14:47 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Maybe he doesn't need fire-proof doors all the time, but is also not satisfied with a hole in a wall -- sometimes a door itself would be sufficient.

Coming back from your analogy: Implementing "just a door" in SELinux is horrible work, and many users then take the hole in the wall instead, i.e., they shut it off. I see this daily at my customers' installations.

Decisions about security mechanisms are not black and white, like all other security decisions. They are a compromise between effort, risk, and asset value. Sometimes the big hammer SELinux is the tool to use, but there are other situations, too -- and not all of them demand the big hammer.