Greg KH wrote: > On Thu, Jul 19, 2001 at 10:15:33PM -0700, Crispin Cowan wrote: > > SubDomain does not allow confined programs to call mount or umount. SubDomain's > > threat model is only concerned with confined processes and principals external to > > the machine. Unconfined processes don't matter, because there either shouldn't be > > any, or they are there for a reason and are trusted. > > Ok, so then all SubDomain has to contend with is handling hard links. > > But since I know that SubDomain only allows hard (and soft) links if > they are specifically listed in a process's profile, no unknown links > can be created by a process. SubDomain only allows the creation of hard & soft links by confined processes if such permission is specified. But the links may exist anyway, and the permission may be granted. > So the inode that is passed to permission() should only have a dentry > list containing 1 dentry. Reconstruct the path from that dentry, and > bob's your uncle. I also thought of this. It's appealing, and in the common case, it will work. Unfortunately, it leaves a DoS hole (observation due to Chris). Someone with an unconfined, or appropriately loosely confined, process can create thousands of hard links to a file they don't own. The result is that the SubDomain module spends a gross amount of time inside the kernel reconstructing each of many alias paths to a file that a confined process is trying to access. If it was just a mild performance issue, I wouldn't worry about it. But this is a big DoS issue. 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 : Fri Jul 20 2001 - 22:48:25 PDT