When being explicit is too much hassle [LWN.net]

One of the cardinal rules for security-oriented programming is to deny anything that you have not decided, explicitly, to allow. The Linux Security Modules project, which has its code partially merged into the 2.5 development kernel, was designed around this rule: the author of a security module is required to provide an implementation for every one of the (many) hooks provided by LSM. The LSM designers were worried that module authors could miss the addition of new hooks in the future, and thus unwittingly allow actions that their security regime was intended to prevent. By requiring an implementation of every hook, LSM ensured that module authors would always see - and deal with - any changes.

The real result, however, was that real-world security modules were bloated by boilerplate stub implementations of dozens of unused hooks. It also was difficult to make modules portable across multiple kernel versions. Greg Kroah-Hartman finally got tired of all this, and posted a patch which removes the "implement all hooks" requirement. There has not been any real opposition to this change; it will likely go to Linus soon.

Security issues often go this way. The real-world costs of proposed security regimes reach a level where they outweigh the benefits. At that point, the best thing to do can be to back off before people start to develop unofficial ways around overly onerous requirements.

(Log in to post comments)

When being explicit is too much hassle

Posted Dec 5, 2002 21:52 UTC (Thu) by mongre26 (guest, #4224) [Link]

I think this is a common problem with the entire LSM and SELinux model for computing security.

These systems seem to be trying to create a trusted computing base. Unfortunately whenever a system has achieved the trusted computing base status it is generally right after it became completely unusable.

The fact is a little insecurity is necessary to get things done, and I think that the whole LSM approach to security is attacking the problem from the wrong end.

Also one of the key "features" that SELinux and other LSM style security systems have in common is complexity, and that does not help maintenance, or security in the long run.

The complexity comes from the deny all, allow some approach. In comparitively simple situations like firewalls this approach generally works well. Most firewalls need only apply a small set of allows to provide for a large amount of flexibility. Unfortunately when it comes to Operating systems which are infinitely more complex this approach breaks down. What you end up with is a never ending process of debugging where you are trying to figure out exactly what "facility" or "capability" is preventing some program from working. Assuming that you do finally figure out the magic set of capabilities that will let you get actual work done you now have to maintain it, In practice the complexity and effort required to maintain the system will ultimately result in lower security as compromises/mistakes are made.

An approach I personally prefer, and one that is now ported to Linux is systrace. From what I have seen systrace is a much more manageable solution to restricting access, at least at the process level. Systrace combines two key features, a learning mode to understand what a process needs access to, and a restrictive mode where a process is not allowed to do anything but what it has done before.

This allows you to apply security policies on a process by process basis, which I think is more workable in practice than a one size fits all capabilities model. Systrace also maps well to how systems are currently managed ie based on the service that they provide (http, smb, nfs etc...).

Systrace allows you to secure the vulnerable external services where most attacks come from. It also helps to manage risk from zero day exploits based on various types of out of band input and buffer overflows in a way similar to privilige seperation in servers like OpenSSH. While systrace is not perfect it does improve things without sacrificing manageability.

Overall systrace probably fits our current security concerns a lot better than other more complex kernel level solutions.