On Wed, 18 Jul 2001, Crispin Cowan wrote: > In SubDomain, we need to know the absolute path name of a file that a > process is trying to open. LSM used to have a hook in namei that let us > construct this name. More recent versions have removed this hook in favor > of a hook at the inode level. Several people claim that it is > easy/possible to reconstruct the path name from the inode. We've been > struggling for some weeks to make this practical, with little success. 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. 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 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? 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? If your module is relying on attach_pathlabel, there will be a number of cases where it gets bypassed. -- Stephen D. Smalley, NAI Labs ssmalleyat_private _______________________________________________ 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 - 06:18:26 PDT