-----Original Message----- Date: Fri, 13 Jul 2001 11:22:15 -0700 From: Crispin Cowan <crispinat_private> Organization: WireX Communications, Inc. To: linux-security-moduleat_private Subject: Re: Security through Permissiveness: A Zen Riddle? <DELETIA> Saltzer & Schroeder 1974 http://web.mit.edu/Saltzer/www/publications/protection/index.html codifies the "default fail safe" principle: by default, an access control system should always deny access, and only grant access after due consideration. At first glance, this would argue strongly for the permissive model. However, supporting a permissive model means that the LSM hooks enable a module to grant arbitrary accesses. If someone provides a broken module, it can make security on the platform much worse. If we apply the default fail safe principle to the kernel itself, then the kernel should permit only restrictive modules. The compromise position is that Linux already supports POSIX.1e capabilities, which provides a permissive security model. Since that code is fairly old & stable, we believe it can be maintained without substantial additional risk. For all other LSM hooks, we prefer to stay with the restrictive model, so that one can relatively easily be assured that LSM modules are not making things worse. <DELETIA> I was under the impression that the capabilities code was seen as somewhat monolithic and a pain to deal with, and precisely the kind of thing that the LSM hooks would allow to be modularized and separated. Which is to say that by allowing no permissive hooks, the LSM is dictating the use of capabilities, or a different security policy. And, again, IIRC it is a project goal that the hooks oughtn't to dictate policy (indeed, that the point of the project was to separate security policy). If someone supplies a broken module, they can cause your kernel to not boot. Or compromise permissions on your system. Or silently truncate your logs. That remains true whether the kernel incorporates LSM hooks or not, so the default fail safe principle is at least difficult, perhaps impossible to apply to the kernel. In other words, that principle is and will be violated no matter what decision is made wrt the placement of hooks. As such, it seems to me that the LSM hooks should support a permissive model so that the principle can at lesat be applied aggressively at the level of security policy, which should be outside the demesne of the hooks themselves. I'm betraying a certain naivete as regards the kernel political process, I'm sure, but I would like to see as eventual goals of this project the ability for an _administrator_ (not a module creator or kernel hacker) to implement policy on his system by integrating (potentially several) modules, each one capturing some portion of the intended policy; the ability for an administrator to use security modules from (potentially) many different sources _at the same time_; the ability for an administrator to use particular modules at different points (read: the ability to gracefully load and unload modules without effecting other modules). These goals point to an expanded effort along the lines of JMJs chaining, but also to an abundance of hooks admitting of permissiveness as well as restriction. -- Matt _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Jul 13 2001 - 13:10:36 PDT