On Fri, Aug 10, 2001 at 10:39:34AM -0400, Stephen Smalley wrote: > > On Thu, 9 Aug 2001, Greg KH wrote: > > > - About /proc. One word: Don't! If you dig through the archives I > > have explained how a module should be exporting information that it > > wants to userspace, create a filesystem. It's easy, fast, and the > > way to do things. See the current sockfs, ramfs, tempfs, usbdevfs, > > and others for examples of how to do this very simply. This is the > > way of the future, get used to it. In fact, I recommend this over > > using a syscall for most interactions with the module (like for > > instance, loading profiles into SubDomain.) syscalls do have their > > place, hence our need for 1. > > I don't think this works well if you are trying to provide extended > forms of current system calls in order to pass additional security > information. Also, how do you deal with output parameters for > syscalls when using a pseudo file system? Passing pointer > addresses as data to a write seems ugly, and doing a write-read > sequence seems problematic for atomicity. Finally, the pseudo > file system implementations seem like they are even more prone > to bugs (e.g. in the parsing of the data) than syscall implementations. Note I said "most" :) I agree. A syscall interface is needed for those instances where you are extending current syscalls like SELinux is doing. Hence the syscall hook. I'm thinking of the SubDomain case where the current code uses a sysctl interface. That could (and should) be easily replaced with a filesystem access. Many other interfaces (like anything that you are tempted to place in /proc) should also be placed in the filesystem. Pointer addresses to a write is ugly, but sending the data and reading the data directly is not. thanks, greg k-h _______________________________________________ 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 Aug 10 2001 - 08:35:46 PDT