On Tue, 13 Feb 2007, Andi Kleen wrote:
> > sys_exec and other security boundaries must be synchronous only
> > and not allow async "spill over" (consider setuid async binary patching)
>
> He probably would need some generalization of Andrea's seccomp work.
> Perhaps using bitmaps? For paranoia I would suggest to white list, not black list
> calls.
It's actually more likely a lot more efficient to let the system call
itself do the sanity checking. That allows the common system calls (that
*don't* need to even check) to just not do anything at all, instead of
having some complex logic in the common system call execution trying to
figure out for each system call whether it is ok or not.
Ie, we could just add to "do_fork()" (which is where all of the
vfork/clone/fork cases end up) a simple case like
err = wait_async_context();
if (err)
return err;
or
if (in_async_context())
return -EINVAL;
or similar. We need that "async_context()" function anyway for the other
cases where we can't do other things concurrently, like changing the UID.
I would suggest that "wait_async_context()" would do:
- if weare *in* an async context, return an error. We cannot wait for
ourselves!
- if we are the "real thread", wait for all async contexts to go away
(and since we are the real thread, no new ones will be created, so this
is not going to be an infinite wait)
The new thing would be that wait_async_context() would possibly return
-ERESTARTSYS (signal while an async context was executing), so any system
call that does this would possibly return EINTR. Which "fork()" hasn't
historically done. But if you have async events active, some operations
likely cannot be done (setuid() and execve() comes to mind), so you really
do need something like this.
And obviously it would only affect any program that actually would _use_
any of the suggested new interfaces, so it's not like a new error return
would break anything old.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
