Re: 2001_05_09 patch against 2.4.4

From: jmjonesat_private
Date: Tue May 15 2001 - 15:05:02 PDT

  • Next message: Chris Wright: "Re: 2001_05_09 patch against 2.4.4"

    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.
    > >
    > > 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.
    > 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
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Tue May 15 2001 - 15:06:45 PDT