I don't know why I did it, I don't know how I did it, but somehow I managed to reverse part of GrSecurity into a set of kernel hooks—only three right now—to implement GrSecurity with. I know Brad isn't going to go along with it, nor will Linus; it's purely academic.
It took me about 5 minutes to design a stacking mechanism that modules don't have to be aware of, and 10 minutes to implement it. It requires two more void pointers per loaded security module, and basically turns them into a doubly-linked list. This list is read-locked and iterated by the security module framework for every security call.
In this design, security calls don't block eachother, because read-locks are non-blocking. When a pending write-lock exists, it blocks all future read- and write-locks until it gains control and unlocks. In this way, inserting and removing modules is safe; and insertion and removal is the only blocking operation. This provides a fast, SMP-aware, self-stacking security framework.
The design I used also leaves any non-supplied functions initialized to NULL for each module. NULL functions are ignored by the framework, instead of being called. This means that no functions are needed. Because the framework also checks for the
grsecurity_ops pointer to actually point to the head of a linked list of modules, the need for a dummy module is also eliminated.
This leaves only the actual important security concerns, such as, how do we determine if we deny or allow an operation? This is quite simple. Along the way, every module has a chance to deny access. If any one module denies access, the check is halted, and an access error is returned. This means that access must be granted by all security modules, or access is not granted.
I find myself asking why no upstream kernel developers have bothered to write this into LSM yet. Perhaps they simply don't want stacking; or perhaps those kernel devs are lazy. Maybe they're just not smart enough.
Stacking is important to allow multiple isolated modules to function together. GrSecurity's kernel security,
chroot() jail modifications, and RBAC system could all be isolated modules functioning together on a security framework. Similar systems could be ported to LSM; but it'd be a waste of time without stacking. Many systems aren't mutually exclusive; they shouldn't be forced to be.
Apologies for this short, irrelavent post. I just haven't had anything to say in a while, and didn't want my readers to think I was dead.