On 10/29/07, Crispin Cowan <[EMAIL PROTECTED]> wrote: > To reject an LSM for providing "bad" security, IMHO you should have to > show how it is possible to subvert the self-stated goals of that LSM. > Complaints that the LSM fails to meet some goal outside of its stated > purpose is irrelevant. Conjecture that it probably can be violated > because of $contrivance is just so much FUD.
LSM is providing bad security on two fronts. Number 1 LSM are speeding effort to create features. Apparmor and Selinux both provide file access filtering from applications. Yet they double up the code to do it. So they cannot be used with each other without doubling up hooks. Then other LSM are creating there own sections of code to do the same thing. Simple rule more code more risk of bugs since it will be less audited. Duplication defense features is really bad for security. Some how code sharing has to be got into LSM construction. Number 2 The critical bit LSM stop at the edges of applications. Now without overlapping my hooks with existing LSMs I cannot create application level protections. Overlapping hooks will cause speed loss. LSM is set to protect the application. But inside the application there will be sections that need the access rights and others that don't. Now a exploit in any section of the application under LSM gets the LSM assigned rights. With application level this can be done a few ways extension to elf that is create by the complier and api calls lowering access functions of current thread or for a starting thread. If you exploit a section of the code without access to disk network access and so on and without the right to call any function that does that. What have you exploited. Minor data damage compared to complete data that the application have access to being stolen as what is the case with LSM at moment. Basically LSM prevent taking control of the complete system but don't help to stop peoples private data from being stolen. Both are bad to happen to a person. LSM design is there to help security development not get in its way or to cause bitrot. Currently LSM design is causing major risk bitrot in duplicated code. Reading and processing configuration files should be independent to the protection methods. Hopefully designed to be able to run user mode to test if the new profile for a application is safe to add before adding it to the OS. Typo prevention on both sides. Current method of just sticking everything into one huge blob is preventing code sharing and risking more security holes. The current LSM design is bad on so many levels. I am surprised that it takes a Non PHD System Admin to see it. Some how I think its a empire thing. If everything was just simple blocks a person could write a new LSM in hours with pretty good security. Compared to todays long time trying effort. Leads of Apparmor selinux and so on not being prepared to give up there little empire for the greater good. I personally hate stacking as a idea. I personally prefer two layers only. Config reading and enforcement. Of course that does not stop applications being assigned to different config reading systems. Depth the two layers should stay fixed even if you have many different models in use. All LSM seam to want to force System Admins to pick there LSM over another. Instead of being able to pick LSM for task at hand. Same with poor security being better than no security its true. Its nothing strange to find selinux based systems with there security disabled because the Admin cannot configure it. But the reverse is also true that when you have skilled Admins stuck with a system like Apparmor cannot harden the system as far as they could with selinux. Both ways its causing security holes poor security when you should have good security is bad too. Part of the problem LSM maintainers are not at the front lines is all I can guess. Because they don't seam to know what is really needed. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
