Re: intercepting system calls

From: Tim lawless (lawlessat_private)
Date: Sat Apr 14 2001 - 06:34:03 PDT

  • Next message: Crispin Cowan: "Re: [lin-sec-mod] Re: Meeting"

    On 13 Apr 2001, David Wagner wrote:
    
    > Tim lawless  wrote:
    > >Further, system call interposition will be problematic for some
    > >systemcalls. For example, execve(). This one is a
    > >'they-check-in-but-don't-check-out' function.
    >
    > Why is this a problem?
    > The 'execve() returned' event is not meaningful unless execve() failed.
    
    It can be meaningful. For example, if a setuid program is execve()'d ,
    and we are monitoring via a wrapper of the systemcall, we would not
    be able to catch the setuid execution event within the wrapper.
    
    The result is that if the security model is intrested in catching these
    events (ie execution of a setuid root program for example) all syscalls
    will that are wrapped will have to check the userid of their calling
    process to verify that its userid and its parent's userid match, checking
    against an internal state database.
    
    Devitations indiciate that a setuid process has been run (this is also
    assuming that the setuid() family is also being monitored and accounted
    for in the state database). This is costly, and hackish.
    
    
    
    >
    > >Other, less problematic syscalls also exist -- vfork.
    >
    > Why is this any harder than fork() or clone()?  In fact, vfork()
    > seems to be a special case of clone().
    >
    > I think that I am having trouble understanding your mental model.
    > Are you and I making different assumptions here somehow?
    
    
    It is tempting to do processing in the child-thread of a vfork
    call -- it doesn't get blocked like the parent. However, it is
    also dangerous by its nature. The monitoring security module would
    be restricted in what it can do, function-call wise, without
    generating some rather magnificant fatal oopses[1].
    
    [1] I learned this the hard way when trying to handle a
        vfork-execve sequence would generate a systemcrash, it was
        traced down to a staticly declared varable that when pushed
        on the stack would trash current. replacing vfork with fork
        eliminated the problems and was how I began to debug and
        narrow down the cause.
    
    
    >
    > _______________________________________________
    > linux-security-module mailing list
    > linux-security-moduleat_private
    > http://mail.wirex.com/mailman/listinfo/linux-security-module
    >
    
    -- 
    There are a thousand hacking at the branches of evil to the one
    who is striking at the root.
    				--Henry D. Thoreau
    
    
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Sat Apr 14 2001 - 06:31:53 PDT