On Mon, 14 May 2001, Chris Wright wrote: > > 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? > > Thanks, I hadn't taken the time to really look at this yet. My only concern > is overhead. Isn't readpage going to get called _a lot_ when reading a > file? Just read mm/filemap.c, and the sitution is uglier than I originally thought. readpage() is of course only called when a page is not found in the page cache (and yes it is called per page not found in the page cache!) Unfortunately, this means that you can't just hook readpage - you'd have to modify generic_file_read, and then audit all usages of the page cache throughout the kernel! > > 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. > > Heh...as far as the list archives go, this is akin to a can of worms. ;-) > Basically, because you can pass open file descriptors between processes > (via fork or sendmsg/recvmsg for example) you can't exclusively rely on > open() (and bind() is not "required" for socket communication). Thinking about it, I'm going to have to rummage around in my utility draw for my can opener, I'm afraid. Oh dear! Worms everywhere. The UNIX way (tm) is to do permissions checks at file open time. Trying to hook into read/write ops may well lead to a mess - see the sticky page cache issues above. I think the passing descriptors between processes issue may have led down a wrong track. A solution is to ensure that a process _never_ gets its hands on a file descriptor which could be used to violate security policy. This shouldn't require too much work at all. The fork() case shouldn't be an issue - the child process must inherit the same security labels as the parent. If the parent wants to fork off a child in a less sensitive security domain, then existing UNIX mechanism should be re-used if possible - namely the "close-on-exec" property on a file descriptor. Once all relevant fd's are closed, the security credentials of the child may be re-evaluated to a lower sensitivity, during exec(). The sendmsg() passing of file descriptors falls out nicely too. When the socketpair() is created, the file descriptors will get labelled with the sensitivity of the creating process. You can't give away a sensitive file descriptor because the process at the other side of a local socket must have the same security clearance. Can you still think of a case where read/write hooking is necessary? 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 : Tue May 15 2001 - 13:56:38 PDT