On implicit type attributes based on pathnames at runtime: It appears to me that, given a dentry and vfsmnt, we need to be able to find a real pathname for a file (disregarding hard links as always, which i'm sure we all have our own ways of dealing with :). Also, from what i understand about selinux' way of doing things, they also will need to be able to see through bind mounts, multiple mounts and private namespaces, in order to ensure that, if /a/b/c is assigned a label, but nothing below that, then /a/b/c/d/e/f will be assigned the same label, even if /a/b/c/d/e has been mounted --bind to /d/e/a. For instance. But maybe I misunderstood, and every single inode on the system is actually in the backing file. The way I solve this is to attach two pointers to struct vfsmount, one to the real vfsmount parent, and one to the real dentry parent. Of course, I allow a policy to specify that given devices must be mounted at certain pathnames (that would be done in a lsm module, I only mention it to clarify that the resulting pathnames are not only unique, but also not predictable :). But the two pointers we would definately need. A modified d_path which follows those pointers could be part of lsm, or part of an lsm module, so long as the necessary info (full dentry and vfsmount trees) is available in modules. My understanding of per-process namespaces is that this solution would work for them as well. Of course, if we ask to modify the vfsmount structure, we may be asking too much. But if we can't do that, then perhaps we *should* remove the other pathname-based label assignment functions, in order to give the rest of lsm a better chance. Naturally, that is not my preference. Comments? -serge _______________________________________________ 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 Jun 29 2001 - 03:41:30 PDT