Stephen Smalley wrote: > It is certainly possible to reconstruct a pathname from an inode, but from > your message below it sounds as though you want the particular pathname > requested by the application. Yes, that is precisely what we want. > That sounds very similar to a request by the SGI folks. But I don't > understand the rationale. Do you want to protect a file differently if it is > accessed via one pathname than if it is accessed via a different pathname? > That seems very prone to vulnerabilities. A concrete example, perhaps? If you think of it from the perspective of protecting a file, then you're right, it makes no sense: you need to block all the possible ways to get to the file. However, we're doing the *dual* of that. SubDomain doesn't protect files, it confines processes, rather similar to chroot. In SubDomain, you specify the names of all the files that a give program may access. When that program executes, it is instantiated as a process confined by a profile that prescribes the set of named files the process can access. Every time the process calls open, SubDomain resolves the call into a name, and checks to see if the name is on the "allowed" list. If it's not on the list, the access is denied. > > If we can't build a practical means to reconstruct the path name from the > > inode, we may want to put the name hook back in again. We feel that it is > > reasonable for an access control module to want to know the name of a file > > being opened, and LSM should provide *some* way of determining that name. > > So what would this mean for Serge's new hooks? I don't know. I was troubled when they went in, because we had not yet resolved whether there was an alternate means to reconstruct the requesting process's view of the name of the requested file. We still don't know if its possible. Serge has shared some code with Chris, which he is evaluating. > And how would you address the fact that lower-level VFS functions like > lookup_one_hash and vfs_create/mkdir/... can be called directly by specific > file system implementations (like nfsd) or even LKMs? In the mode described above, we don't care. We're trying to confine programs, not protect files, so it doesn't matter to us whether there is some other way to access the file. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ 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 : Thu Jul 19 2001 - 12:20:36 PDT