"David Wheeler" <dwheelerat_private> > Jesse Pollard <pollardat_private> said: > ... > >This calls for a fileserver (possibly using NFS) that can interpret > >security permissions. For one part, the NFS server daemons need to be > >able to determine whether access can be given (it IS acting on the > >behalf of a file system). Current procedures require the NFS daemon > >to switch UID/GID to the user BEFORE attempting to access the file. > >This is error prone. It introduces a DoS attack (the user is able > >to abort the daemon while it is doing the access). > > No, not in Linux, if I understand you correctly. > > The canonical method for doing this in Linux is to use > setfsuid(2), a Linux extension. This forces the process to access > all files as the given user, yet doesn't let the user send signals to > the daemon. See the setfsuid(2) man page for more details. Yes - I think that is why the exension was added. But does make the server code less portable. The exension, however, doesn't include capability matching as well. And that can also affect the result. (I know - the remote context is not fully accessable to even do this... But I think about it becoming available via IPSec and the extended security headers). I would like the extension to become part of the interface into the security module (optionally). Then the entire security evaluation thing could be abstracted into a single (application) library function that could handle ACLs, DAC, and MAC, accesses. Or the function could just devolve into a setuid/setfsuid ability. ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollardat_private Any opinions expressed are solely my own. _______________________________________________ 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 : Tue Apr 24 2001 - 14:30:54 PDT