Lets start with a few basic problems I have found with all LSM's I have tried.
Number 1 they forget users might need to limit applications without administrators approval and only locally. This is like running Firefox locked out from seeing a particular directories choose by the user because the user know they contain stuff that should not be seen online. Most of the limitations a system admin can apply to applications users need to be able to apply to there own. Of course user should never be able to grant more permissions than what they have. Number 2 most are attempting to fix the suid and the guid bits defects yet it never is attempted to be addressed kernel fault/Posix design fault. Posix file capabilities get close. Even that these cannot be used to replace suid and guid they should be made able to used to provide limitation to them. Number 3 they all seam to take there own path saying that they are better than the other. This should not be. It should be does the linux kernel have a defect and can we share fixing it. This is a future one I have not seen a security containers so that different sections of a virtual server could use different security modules. There are also some important questions. If its right to break down root powers for applications is it not equally right to be able to break down root powers for users? If its right to break down root powers for applications should not users have the means to break down there powers for applications as well? Now these questions are not a LSM by LSM question should be a common feature for everyone question. In my eyes almost every restricting feature that LSM use should be setable by anyone on the system to suit there needs just like the same way everyone can set there own permissions bits and acls now. Of course that does not ever over rule the LSM they can only set more limited than what the LSM allows. Ie restrict more. Final thing of this would be getting these security settings for users into the desktops. Basically LSM come like Virtual Servers and Secuirty locks like Containers. LSM take up a supervisor role integrating the inbuilt linux security into one system Secuirty Locks on offer vendor neutral. Will there always be room for LSM's yes as monitoring and different ways setting the locks. Note the means to set security limitations on a application by application base for the user will be particularly handy for programs like wine that could run viruses or other harmful things to the user. Yet due to wine own ability to have other user directories set for its data its kinda imposable for a system admin to use selinux apparmor and other to contain it from destroying the users home directory. Yes I do perfectly agree with Linus refusing to take one LSM into kernel. He also refused to take Virtual Servers into the server. Same problem many different models. Containers provide a common ground between the Virtual Servers so they are getting in. On top Containers provide users with other features they never had before like limiting the ram a particular application or set of applications can use. Extending the linux security system will do exactly the same. Yes it may mean going into new areas away from posix designs. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
