Re: 2001_05_09 patch against 2.4.4

From: Chris Evans (chrisat_private)
Date: Tue May 15 2001 - 13:55:17 PDT

  • Next message: jmjonesat_private: "Re: 2001_05_09 patch against 2.4.4"

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

    This archive was generated by hypermail 2b30 : Tue May 15 2001 - 13:56:38 PDT