David Wagner wrote: > Jesse Pollard wrote: > >A file may have its permissions changed to deny the process access. > >[...] may want to deny access to a file after forking [...] > > Well, if you want a policy that has these semantics, then you > can't take advantage of not trapping on read()/write(), that's > true. Fair enough. > > On the other hand, this policy is "Not The Unix Way", as someone > alluded to earlier. In Unix, file descriptors are capabilities. I disagree about "not the unix way". Precisely because file descriptors are (kind of) capabilities, and they can be passed around in a lot of sloppy ways, it is ineffective to pretend that restricting the right to create such capabilities restricts the right to access the files. The capabilities themselves must be mediated via read & write. Or at least the ability to allow some modules to mediate read & write must be provided. > And yes, performance will hurt under such a policy, but I'd argue We found that, in practice, it does not. The read and write checks are relatively fast, and read & write themselves are relatively slow. Conversely, if someone presented me with a mechanism that promises that file descriptors don't leak across processes, I'd have a VERY hard time convincing myself that it was correct. 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 - 10:09:54 PDT