On Thu, 10 May 2001, Chris Wright wrote: > > 3) There's a problem brewing with regards lack of central control points > > for logically equivalent operations. > > For example, in file_security_ops, I see separate hooks for mmap, read, > > write, readv, writev. But, logically, mmap(..., PROT_WRITE, > > MAP_SHARED, ...) is equivalent to write(). > > Lack of central control may result in a module blocking access to some > > operation, but leave a "backdoor" where the same operation is let through > > by a different syscall sequence to achieve the same effect. > > This I _really_ agree with. In general I am in favor of pushing hooks to be > as late as possible to deal with multiple access points to the same kernel > object/data/whatever. This is our first attempt at abstracting what we need > to protect. It is _far_ from complete, and I suspect will look a lot > different when we are finished. > > As far as the mmap example you've highlighted, I think we still need to > protect the mmap file operation. For MAP_SHARED and PROT_WRITE it seems > like we could simply add a write check for consistency... > (in do_mmap_pgoff) Hi, I'm not so sure you want to add special cased code in mmap that "knows" MAP_SHARED, PROT_WRITE && !MAP_ANON is equivalent to a write operation. The "pushing hooks to be as late as possible" sounds like it may be the way forward, but wouldn't that mean looking at "struct address_space_operations": readpage, writepage? Unfortunately, (and ICBW), this doesn't handle non-pagecache entities like block/character devices. Or directories. Ho hum. BTW, I don't think your current hooks would catch a sendfile() operation, which IIRC goes through the unhooked readpage() rather than the hooked read() or mmap(). In fact is there much value to attempting to hook read()/write() operations at all? Shouldn't access be controlled at open() time? (or bind() time for sockets). Something like MAC should work with just that. Cheers Chris _______________________________________________ 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 : Mon May 14 2001 - 17:52:35 PDT