On Tue, 15 May 2001, Chris Evans wrote: > > 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! The trouble with tribbles. :) They multiply all over the place. > > > > 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(). Um, what do you mean by "reused"? Certainly the userspace code shouldn't have to close files or mark them explicitly. And there's no sure way to determine which files are relevant. If you mean implicitly dup the descriptors during an exec, then close them, then reopen them using the new permissions... that's a once-in-while occurance and the overhead should be tolerable, as long as failure of any of those "manipulations" returns a failure to the parent so she knows that the child didn't get it's "vitamins". > > 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. True. > > Can you still think of a case where read/write hooking is necessary? > Suppose there's a crack that replaces the task's code at some point after the file is opened? Subsequently, a sensitive file (e.g. /etc/passwd) may be compromised during a read or write from what apparently is a valid process. The capabilities module MAY wish to restrict *certain kinds* of read/writes as being "suspicious". Not sure if I can think of a case where this might happen in practice, except, possibly, adding a line to an auth file... a poorly programmed task might open w+ to read/modify a file and the "evil" may wish to extend that file... which could be a prohibitted activity according to policy. By providing a hook during reads and writes that passes the params for that operation, a finer grained "checking" may be possible. Just a thought, maybe not such a risk. > Cheers > Chris > > J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 - 15:06:45 PDT