Rob Meijer wrote:Clearly what is needed here is for someone to actually implement an object capability LSM module. None of SELinux, SMACK, LIDS, AppArmor, MultiADM, or TOMOYO can implement object capabilities, so there is clear justification for building such a module. I would argue strongly to include it. I *really* dislike this idea. It seems to set up the situation that the only acceptable modules are those that follow some "formal" model. Problems: * What qualifies as a formal model? This becomes an arbitrary litmus test, depending on whether the model was originally published in a sufficiently snooty forum. * What if someone invents a new model that has not been "formalized" yet? Should Linux be forced to wait until the idea has been through the academic mill before we allow someone to try implementing a module for the idea? * The proposal only allows a single implementation of each formal model. In theory, theory is just like practice, but in practice it is not. SMACK and SELinux follow substantially similar formal models (not exactly the same) so should we exclude one and keep the other? No, of course not, because in practice they are very different. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work -
| Linus Torvalds | Linux 2.6.27-rc8 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Linux 2.6.20-rc6 |
| Mike Snitzer | Re: Distributed storage. |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Herbert Xu | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state ch... |
