Re: RFC: sys_execve security kernel mod

pollardat_private

---------  Received message begins Here  ---------

> 
> On Thu, Jun 20, 2002 at 07:10:06PM -0700, J. Paul Reed wrote:
> > On Thu, 20 Jun 2002, Greg KH wrote:
> > 
> > > Sounds like the same idea as CryptoMark:
> > > 	http://www.immunix.org/cryptomark.html
> > > But it uses GPG keys to sign binaries.
> > 
> > I'll take a look...
> > 
> > > It is a nice idea.  Be careful of replacing syscalls, it's non-portable
> > > and extremely racy.  I'd recommend using the LSM interface for your
> > > execve() hook, which removes all of those problems.
> > 
> > We took extreme care to make sure that it *was* portable; how is replacing
> > the system call, in the manner we've implemented it, non-portable (please
> > excuse my obvious kernel-ignorance :-)
> 
> I take it back, you aren't replacing the sys_execve system call, you are
> using the loader table, which is the proper way to do something like
> this.  Very nice job.  You do try to disable the load_module() and
> friends syscalls, which I would just drop if I were you.  They provide
> no real security at all.  And your replacement of them is racy.  See:
> 	http://www.kernelnewbies.org/faq/index.php3#intercept
> for an explaination of why replacing the syscall table entry is bad (and
> specifically, why replacing sys_execve() is so tough :)
> 
> And I like what you are doing with the inode caching.  That solves the
> major problem that I had when developing CryptoMark, namely the speed
> hit.  Your cache, at first glance, seems like the proper way to not have
> to constantly check the file for every time it is executed.  But I'm not
> so sure that mtime could not be faked, so you might look into how secure
> this really is.

Of course mtime can be faked - just look at touch - it modifies access time
(-a) and mtime (-m) dates associated with the file. The only way to stop that
would be to put a cookie into the inode that gets cleared on any write to the
file data blocks and where ctime or mtime fields in the inode are modified.

And if you look at tar - it creates files with any creation/access/modification
date as specified in the tarfile.

> I hope you two got a good grade for this, it's a nice piece of work for
> a tough problem.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module