Crispin Cowan <crispinat_private> wrote: > 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, So there is only few ways I know of to pass file descriptors between processes. Through inheritance via. fork/clone. Through shared descriptor tables via. clone. Through descriptor passing via. sendmsg/recvmsg. I don't see why these are "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. Fair enough, one still has to worry about core dumps for example. But there are few of these cases. In general I think that controlling access to descriptors provides an extremely effective mechanism for this. >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. Why?, if you want to control access at the level of granularity provided by normal unix permissions (read/write etc.) then simply controlling access to descriptors is fine (again modulo stuff like core dumps). If you wish to provide finer grain control you can simply pass along more restricted capabilities, (for example socket or file descriptors that filter read/write based on content) and this can be implement via. the existing device driver interface, or by passing descriptors to user level processes which mediate access. > 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. I don't understand this argument. The sharing of descriptors respects some small, well defined set of semantics, just like the rest of the system. If you think that the semantics of the current Linux API could be improved in order to facilitate the use of descriptors for constructing more general security policies then I would concur, and would be intrested to hear what changes you think should be made. --Tal _______________________________________________ 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 Apr 27 2001 - 11:16:15 PDT