I am cross-posting this to LAD, hoping to get some useful feedback. Paul Davis <paul(a)linuxaudiosystems.com> writes: I spent some time last night looking at... (*) linux-2.6.0-test9 kernel sources (from Debian) (*) SELinux 2.60-test6 sources from NSA, http://www.nsa.gov/selinux (*) the Linux Security Modules web site http://lsm.immunix.org As always with the web it's hard to tell the real stuff from the vaporware. But, this stuff looks real to me. :-) SELinux (Security-Enhanced Linux) is NSA's research project for implementing DoD Orange-book security features as a pluggable kernel module. Almost all of the SELinux modularization changes are present in linux-2.6.0-test9. Their entire compressed patch for the 2.6.0-test6 kernel was only 1889 bytes containing 189 lines of context diffs. By comparison, they also distribute an SELinux patch for 2.4.21, which is 209KB (compressed) containing almost 36,000 lines of context diffs. Internally, the 2.6 kernel exclusively uses `if(capable(CAP_foo))' tests, AFAICT. That was already (mostly) true of 2.4. In 2.6, there are pluggable security modules to control the semantics of these tests. The vanilla test9 kernel includes a small example security module, `security/root_plug.c', which tests for the presence of a specific USB device at exec time, only allowing setuid if it is present. It is only 143 lines long. Domain and Type Enforcement (DTE) is another project using a loadable security module. It seems to be aimed at Mandatory Access Controls for partitioning the file access capabilities of root processes. The idea is to run root daemons in a "Domain" that lacks the ability to modify important system files like /bin/login and /etc/passwd, frequent targets for evil crackers exploiting buffer overflows in their victim daemons. ;-) This leads me to believe that 2.6 *does* permit one to write a kernel security module for selectively granting realtime permissions to certain processes. The mechanisms provided are far more powerful than necessary for that simple application. I don't know exactly what realtime security policy should be implemented and how the underlying mechanisms ought to be used, though I have some ideas. But, the first step is to figure out if someone is already working on this. My late-night googling didn't discover any existing project, but surely someone is doing it by now. If not, I think we should consider building and distributing one as part of JACK. Comments? -- joq