Re: RFC: sys_execve security kernel mod

From: Jesse Pollard (pollardat_private)
Date: Fri Jun 21 2002 - 06:13:18 PDT

  • Next message: Greg KH: "Re: RFC: sys_execve security kernel mod"

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

    This archive was generated by hypermail 2b30 : Fri Jun 21 2002 - 06:14:28 PDT