On Thu, 5 Jul 2001, Crispin Cowan wrote: > That has limited effectiveness. You want to say "can't modify /etc/hosts.allow" > and what you end up saying is "can't write to /etc". Otherwise, you end up with > a really weird access control model for directories, e.g. "I have the right to > create a file called 'hosts.allow' in the '/etc' directory if I feel like it." I agree that per-directory controls lack the desired granularity. But as I said in my message, we also provide per-file controls on directory operations like rename, link, and unlink. So you can label /etc/hosts.allow with its own type during initialization and then specifically control the ability to rename or unlink it, based merely on its type, not its pathname. > This approach makes me uneasy. I'm not sure why, but my intition is that it is > relatively difficult to ensure that all means of file creation populate the > inode->name mapping table. I like the name-based model because I can > intuitively trust it. How convinced are other people that this method can be > made sufficiently reliable? I don't follow your argument. The existing post_create/mkdir/... hook calls ensure that the module can bind security attributes to newly created files and directories. In fact, your concern seems to be an argument for those hooks rather than the redundant attach_pathlabel hook calls, because there is much less certainty that the attach_pathlabel hooks will always be called after the vfs_create/mkdir... functions are called. Protection based on pathnames has known problems with multiple hard links, renames, or multiple mounts, so your confidence that a file is always protected consistently regardless of how it is accessed is lower. Finally, the name-based model is inconsistent with the existing Unix model, so the Linux kernel has no incentive to support it in the long term (hence, the increasing move away from being able to determine absolute pathnames). Let me also return to the original point that started this discussion. Some of the attach_pathlabel hook calls are redundant with the post_create/mkdir/... hook calls. Can we at least eliminate those attach_pathlabel calls? As I've said previously, our confidence that the post_create/mkdir/... hook calls are always called for each file creation is much higher, because they are in the actual vfs_create/mkdir/... functions. The corresponding attach_pathlabel hook calls must be inserted after every call to the vfs_create/mkdir/... functions, but those functions are exported to modules, so we could easily end up with "unattached" inodes in the system. Also, can we do some analysis of the other attach_pathlabel hook calls to see if they might be bypassable? Again, this is my motivation for pushing them down to lower-level lookup hook calls, so that I can have greater confidence that every inode gets "attached". -- 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 : Fri Jul 06 2001 - 05:53:36 PDT