Re: intercepting system calls

lawlessat_private

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