Re: 2001_05_09 patch against 2.4.4

chrisat_private

* Chris Evans (chrisat_private) 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!

yuck, this is what i was afraid of ;-(

> > > 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.

heh, yup.

> 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().

Alright, say for a moment we did completely manage the issue of passing file
descriptors between processes.  Monitoring read/write in addition to open
adds a level of granularity that I think may be necessary to support
changing domains while in the same process (dropping privs while executing
some unsafe code path).  SubDomain (and likely other projects) allow changing
security domains without fork/exec.  We support more restrictive domains while
running perl code from modperl within apache for example.

-chris

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module