--- "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> wrote: > A couple of random thoughts to mix up this discussion. > > From what I have been able to observer the LSM is roughly firewalls > rules for in box operations. All it can do is increase the chances > you will get -EPERM. More likely -EACCES, but otherwise not so terribly far off. > Not being able to take path names into consideration is a current > deficiency of the LSM. It's a deficiency of the file system semantics invented by Kernighan, Thompson, et. al. in the later 1970's, favoring speed and size of implementation over a pristine namespace. The LSM is reasonably faithfull in presenting both the good and the bad of the file system semantics. > Being exported to modules is another deficiency of the current LSM > as it seems no serious user of the LSM can exist simply as a kernel > module. While that is true of SELinux and AppArmor I would suggest that is an artifact of the design goals of those two sophisticated security schemes, not an attribute of the LSM. > Not being able to mix code from different projects is also a very > serious limitation of the LSM. Currently I don't think we can > build a kernel that supports selinux and any other LSM at the same > time. Which horribly limits what we can do with the LSM. Weeeelllll ... Module stacking has been a contentious issue from day one of the LSM. Now that SELiunx is proposing to take over capability processing for it's own purposes it's easy to think that while other schemes may be up to stacking SELinux ain't gonna. > So it seems clear that if we are aiming at an ideal solution. We > first need to enhance the LSM. I don't think so. I see much greater social/political problems than I see technical ones. > Then merge in the AppArmor > functionality. Doing it all in one patch series looks to overwhelming > for a decent code review. It's true that the code review for AppArmor has proven difficult. That's going to be true of any change to the vfs layer, for any reason. Have someone who was there tell you about the original XFS proposals some time. Again, it's not LSM's fault. > That said is anyone interested in making the LSM more like iptables > with a generic table based rules structure? That's pretty close to what you get with SELinux, and one reason why that crowd has advocated that LSM be dumped in favor of SELinux as the sole interface. > That way we could fix > the one true LSM problem and concentrate on simpler pieces that give > specific bits of interesting functionality. Sort of. While the SELinux kernel code isn't much, less than 20k lines, the reference policy it requires is 200k lines, and the smallest policy I've ever heard anyone claim runs is 600. Yes, you get interesting functionality, but I don't recall there being many claims that policy development is simple of late. > Or at the very least > be able to compile in multiple different bits of functionality into > the kernel simultaneously. The LSM stacking problem, to my mind, is waiting on two modules that really want to work together and enough thick skin to get past those who don't want LSM to get better in hopes it will go away. > I'm really not familiar with the security issues the LSM addresses It addresses none, it is a tool put in place so that Linus doesn't have to listen to security people argue over which scheme is better. > but I do know, it encourages huge incompatible mega solutions, That's the security marketplace, not LSM. > and > it tends to break when I fix real security problems in the kernel. Please, examples. > So at this point I am convinced that the LSM is deficient, has very > limited usability, and seems to be a very fragile firewall structure > to me. The "additional" architecture of the LSM, as opposed to the originally proposed "authoritative" model is responsible for a good deal of the limited deficiency and uasability, but was considered necessary to prevent kernel "highjacking". If it's fragile, it's mostly due to the organic growth of security implementation in the kernel. It is under utilized, and there are a number of reasons for that, but recent events are encouraging. Casey Schaufler casey@xxxxxxxxxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
