Stephen Smalley wrote: > On Thu, 5 Jul 2001 sarnoldat_private wrote: > > I'm not sure this is always the case. While it might make great sense > > for user data, there are system configuration files at Well Known > > Locations where the data in the file needs to be protected -- at that > > location. > Umm, no. As you point out, you can protect the directories containing > the files in question. 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." :-) > But let's not go too far on this debate. As I've previously stated, > you can support pathname-based modules without needing to reconstruct > absolute pathnames on each lookup or file creation operation. In fact, > that should be preferable to you from a performance perspective. So > the hooks end up being the same anyway. 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? 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 05 2001 - 23:14:26 PDT