On Thursday 24 July 2003 15:28, Omen Wild wrote: > Quoting Jesse Pollard <jesse@cats-chateau.net> on Thu, Jul 24 15:23: > > The inode becomes equivalent to the name, but with the added fact that it > > is unique. This also allows the user/administrator to rename the file > > without having to recompute the hash. > > I believe that could be a security hole. If my module is protecting > /bin/ls and someone deletes it and copies in a Trojaned version (which > has a new inode #) then that fact would never be caught. If the attacker can do that, then he can just replace the search path environment variable and accomplish the same thing. Using the inode means that ANY path to the binary WOULD be checked. And if the file were deleted ..(actually renamed, because I assume you will be catching any deletes of the inode) and a replacement put in.. is no different than changing the path. Also .. how are you going to handle the "../bin/ls" vs "/bin/ls" vs "/usr/bin/ls", which all may reference the same file. The attacker could replace any of these just to force you to put scads of hash references (especially when /bin is linked to /usr/bin). And how about chroot environments? (likely just ignore them as they may be created on the fly) _______________________________________________ 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 24 2003 - 14:35:10 PDT