>Hans Reiser wrote: >We only do filesystem isolation because that is our specialty, >filesystems, and it is better to do less well. > >We fundamentally differ from other approaches because I don't think the >problem is in developing tools to allow people to fine grain security if >they take the time to do it, I think the problem is that nobody has the >time to specify fine grained security for the executables on their >computers, and our focus is on the filesystem aspects of automating the >specification of the fine grained security for an executable. >Researchers after us can generalize our approach to things outside the >filesystem namespace, or, better, put those things into the filesystem >namespace.;-)
Sounds like your approach will differ a) in scope, in that you are only concerned with securing filesystem access and b) in that you will provide "wizards" where the other approaches provide none or the ones they provide suck. If this is the case, then why are we talking about mask interpreters and how they will moderate file access? Why aren't we focusing on your "sweet spot"; the wizards that assist the clueless/lazy/overworked admin in profiling a process in order to create and maintain the viewprint/mask? If your ultimate concern is truly in providing tools that make it easy to deploy comprehensive security, then it seems the approach to take is to contribute wizards/whatever that make implementing your process-oriented fs security vision incredibly simple under LSM or other framework. If you're only going to focus on your metier, filesystems, and exclusively on your own filesystem, at least contribute something that doesn't reinvent any wheels and which "plays well with others." People do need to secure more than the filesystem. Reiser4's adoption curve would seem to benefit if people can implement advanced filesystem security and also use the same framework to secure other aspects. David
