On Thu, 2005-06-30 at 11:36 -0400, David A. Wheeler wrote: > But then there are various activities that can create > a vulnerability, or help lead to such a state, that you want > to prevent, yet aren't easily covered by a traditional model. > For example: > * Limit filenname creation to certain formats (e.g., forbid > leading "-", forbid control characters, require UTF-8 format), > because some filenames can be easily abused to cause vulnerabilities. > * Forbid following tempfiles/symlinks in certain combinations, > like OpenWall does, because they can lead to race conditions > * Detect sequences that appear to be, in combination, an attack & > prevent them. E.G., an Intrusion Prevention System. I think that this is approaching the problem the wrong way - ad-hoc solutions for specific attacks, rather than thinking about the general problem. For example, malicious symlinks are just a particular instance of the problem of a high integrity process being corrupted by low integrity data. > Nobody will agree on exactly what that set should be, but that's > perfect for loadable stackable modules... just load the > set that describes what YOU want to prevent, given your > expected use of the system. Different expected use, different > set of modules. Or different expected use, different policy configuration. The latter allows you a unified mechanism, policy analysis tools, userland infrastructure, set of APIs, etc. The former is a mess. > > > That would seem to lend itself toward: > >- fragmentation of already scarce security resources that could instead > >be working toward a common unified solution, > > Quite the reverse, I believe. A single LSM > that covers SELinux-like mandatory access controls, > illegal filename patterns, handles OpenWall symlinks, > detects sequences that are malicious, and so on would be > completely unwieldy. If such features are added as ad-hoc solutions to specific attacks,then yes, the result will be unwieldy, but that will be true whether it is done by a single LSM or ten of them. If you consider the general issues and seek a general solution either via configuring SELinux or, if truly necessary, extending it, then it need not be unwieldy at all. You can leverage common mechanism toward solving that problem that already exists to help with other problems. As to fragmentation of scarce resources, it is already evident. > >- most LSMs remaining out of tree, > > I doubt it; people will want them reviewed, which will > push them into the tree. I think if you look around a bit, you'll find that there are a number of LSMs that have been created, and that very few of them have been submitted upstream (and those that have been submitted upstream have not met with great enthusiasm, as their quality has generally been poor). In fact, if you've read the discussions on this list, you'll see that Crispin was surprised that Linus would even want LSMs in the mainline kernel. > >- no stable kernel security model or API due to variances in the set of > >LSMs present in any given kernel and thus no effective leveraging of any > >specific security model or API by upstream applications that want to be > >portable. > > I don't think this dire circumstance needs to occur. It already is. Develop an application on Fedora Core/RHEL, and you'll have the SELinux security model and API. Develop an application on SuSE/SLES, and you'll have either no additional security model and API or you'll have the SubDomain one. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Thu Jun 30 2005 - 11:52:06 PDT