> I fooled around with it and and it seems like there > are these "exempt" > processes? That is, if you hack one of those "exempt" > processes (services) > you can compromise the whole system, right.? So, > what's the point? Isn't the > net result still an insecure system that's more > difficult to maintain? > That's more difficult to deploy? Well, not quite. To be precise there are "exempt files" and "guard processes" (but not exempt processes). Exempt directories are used for things like /tmp, in which applications must be able to create files of differing security levels, which would otherwise not be allowed. Files in /tmp are still labeled. Guard processes are reserved for those few programs, like login, which are inherently part of the TCB, and must be trusted. If you can hack any element of a TCB, you can hack the system, and that is true of any system including EVM/SLIM. This doesn't mean you don't want to do the best you can to block attacks. > And stacker is now being "re-patched"?... ok.. is > there going to be a fork > in the stacker tree? The post_inode_create hook was in LSM, not stacker, (which is worse, since it has been committed to git.) LSM removed the hook because no one was using it, and because it was difficult to use correctly. Unfortunately we still need the hook. > > I would love to have a secure system that is easy to > maintain. What benefit > is gained from deploying this when it appears to be > fundamentally flawed? > ( race conditons.. exceptions, etc ) The low water-mark integrity model is one of the few which *is* fundamentally sound. (There are proofs of integrity confinement for the theoretical model.) Using a hardware Trusted Platform Module (TPM) for secure boot is perhaps the only way to detect all on-line and offline software integrity compromises. Implementation errors, while embarrassing, are easily fixed, and I appreciate anyone who takes the time to point them out. dave
This archive was generated by hypermail 2.1.3 : Tue Oct 18 2005 - 15:27:35 PDT