Seth Arnold <sarnoldat_private>: > We don't need the functionality (well, no one has convinced me :) of > saying "this process could make the connect() if it were running by root > on the third tuesday of the month except for leap years". "Go away" is > sufficient in my book. :) For most user processes, "go away" is sufficient. I work in a site that uses STK tape silos (300+TB) for a file migration backup. The file server itself has ~3 TB of real disk, plus remote tape access requiremnts (not examined yet). 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). A "simple" cure for this level of problem is to move the NFS daemon into the kernel (and adds a lot of bloat code to the kernel). It also adds the possibility that a NFS bug exposes the entire kernel to a catastrophic failure. A "better" (my opinion) would be to give the NFS daemon a "may access users files" blocking access to device inodes. The daemon would then determine if the data is to be supplied to the remote host based on what the security module permits. This requires some way for the NFS daemon to query the security module for permission given the users security context (uid/gid list), and possibly more (privileges assigned the user, host the users request is coming from...). Another place that a daemon would be usefull for is providing remote access to tapes. In this form, the daemon needs the users remote security context, the security labels on/of the tape media, the transports available, to make a query of the security module to determine if a tape should be mounted for the user. This daemon then acts (in conjunction with a client daemon) to simulate a local tape drive on the users workstation/system. Both daemons would need some handshaking (NFSD requires BIODs on clients to pass proper context - and the BIOD should not switch uid/gids either. In some cases, some of the security context should be taken from an IPSec layer that can be used to augment the context exchanged by the daemons. In any case, the daemons really shouldn't be part of the kernel. ------------------------------------------------------------------------- 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 - 07:15:08 PDT