intercepting system calls

From: Jesse Pollard (pollardat_private)
Date: Thu Apr 12 2001 - 07:39:52 PDT

  • Next message: richard offer: "GACI item list - to give some items for discussion"

    Crispin Cowan <crispinat_private>:
    > "Anil B. Somayaji" wrote:
    [snip]
    > > If you want to mess with system calls, you should mess
    > > with them in kernel-space - anywhere else is either too expensive,
    > > insecure, or both.
    > 
    > I don't actually see a performance issue with hooking at the syscall interface.
    > And in fact, you can already hook syscalls by reloading the system call table.
    > The catch is that you don't have much context when you hook at the system call
    > level, i.e. you know the arguments to (say) open, but you don't know anything
    > about the inode number that it will resolve to after it gets through namei.
    > 
    > This is exactly the quandary that SubDomain and LOMAC faced.  SubDomain "solved"
    > it by punting and going with a kernel patch.  LOMAC solved it by re-implementing
    > parts of the kernel in their module.  The security LKM is supposed to relieve
    > security modules from having to use either of these sub-optimal solutions.
    
    It would seem (relative ignorance at the moment) that the permissions should
    be checked in namei, while namei is performing it's lookup. Each permissions
    check should refer to the security module/manager/whatever for grant/fail
    on the activity.
    
    Once namei gets done (successfully), the do_open/do_exec must confirm the
    final action.
    
    The difference between these two locations is that namei may cancel the
    final action with an error; the final action will have nothing to do with
    file lookup. It will either open the file, or exec the file. If exec; then
    the inheritable capabilities/security context... must be determined by the
    security module. If open, then the file permissions only are checked.
    > 
    > > I actually do believe that sometimes you do care that a program is
    > > writing to /dev/null - especially if that program normally writes to a
    > > log file!  But really, what it comes down to is that many people have
    > > proposed and tested effective security mechanisms that work at the
    > > system-call level.
    > 
    > True, but couldn't that be detected through a hook deep down in open?  What just
    > cannot be mediated with hooks in open?  Quick answer:  processes share file
    > descriptors, so you also have to mediate read and write.
    
    have to mediate mmap too.
    
    >                                                           But what else?
    
    Depending on the use of clone:
            sockets (via file discriptors)
    	shared memory
    	semaphores
    	signal events (inherited configuration)
            resource limits (inherited values, until beancounter accounting)
    
    Whether all of these require mediation on fork could be up to the
    security module (or a resource accounting module) is policy dependant.
    
    In one case, the ability to create a network connection must be mediated -
    If the policy requires that "users cannot establish communication with
    unknown remote hosts" then the socket and connect system calls (maybe only
    the connect) have to be mediated by something. This gets difficult when
    some users are not allowed, some are. Those that are, are allowed to connect
    only to a certain class of hosts. Each user may have a different list of
    allowed hosts. Some of this can be/should be part of an IPSec implementation.
    Other functions, like socket/bind, may not be permitted at a low level where
    system call interception would be most efficent. A capability test by
    the security module would grant/deny use of the system call.
    
    The advantage would be that the overhead for deny would minimized instead of
    having to pass the decision up to something like IPSec (which may not be
    present), and still allow for a facility policy that prevents users from
    creating arbitrary servers/network connections.
             
    > > So, while I like the general idea of interposing on system calls, I
    > > see lots of problems with doing it in practice.  I'm curious - what do
    > > other people actually want to do to system calls?  How much info is
    > > needed?  Maybe we can't have a really flexible API, but maybe we can
    > > have one that does 90% of the job for 10% of the effort and 1% of the
    > > slowdown.
    > 
    > That's the goal.
    
    Part of the difficulty is in determining what is/should be part of the
    security context. Some things are obvious (security level, inode, ...)
    others are less obvious (uid, gid, gid list...). And where should capabilities
    be placed - MAC almost certainly, but ACL's have been known to carry
    capability lists, and those are usually evaluated under DAC. (a bit of
    blithering - sorry :-) 
    
    -------------------------------------------------------------------------
    Jesse I Pollard, II
    Email: pollardat_private
    
    Any opinions expressed are solely my own.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:24 PDT