Casey Schaufler wrote: > Crispin Cowan wrote: > > "allowed_to_open()" already exists: it is called "access(2)". Say "man 2 > > access" for details. > access(2) is a queer duck. It uses regular path lookup > to the final component, but the realuid for the object itself. > Further, it does not deal with conditions which exist > today, such as read-only file systems and immutable bits. How unfortunate. However, if we provide a hook for LSM modules to mediate the access(2) syscall, then we enable security modules to do a better job of implementing access(2) if they want to. That may break legacy code that depends on the existing (broken) semantics of access(2), but that's a decision that module designers get to make for themselves. > A useful function, first proposed in literature by > W. Olin Sibert, would be one which you pass a bunch > of security attributes for the subject and a set for > the object along with a proposed access and you get > back a best guess answer. It could be implemented > strictly in userland for many policies. On the other > hand, I've never seens a reasonable specification > for the call. I don't see a problem with LSM modules providing new system calls (or ioctls, or sysctls, or whatever) to provide this kind of functionality. It's yet another module feature, not a feature of LSM per se. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org _______________________________________________ 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 : Mon Apr 16 2001 - 15:49:08 PDT