Re: RFC: disablenetwork facility. (v4)
- From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 27 Dec 2009 20:49:17 +0900
Pavel Machek wrote:
Syscalls are very wrong granularity for security system. But easy to
implement, see seccomp.
Quoting from http://en.wikipedia.org/wiki/Seccomp
It allows a process to make a one-way transition into a "secure" state where
it cannot make any system calls except exit(), read() and write() to
already-open file descriptors.
I think seccomp() is too much restricted to apply for general applications.
Most applications will need some other syscalls in addition to exit(), read()
and write(). Most applications cannot use seccomp().
What I want to do is similar to seccomp(), but allows userland process to
forbid some syscalls like execve(), mount(), chroot(), link(), unlink(),
socket(), bind(), listen() etc. selectively.
Al Viro wrote:
Application writers know better what syscalls the application will call than
Aren't you forgetting about libc? Seriously, any interface along the
lines of "pass a set of syscall numbers to kernel" is DOA:
We can determine what syscalls we need from application's code and libc's code,
Otherwise, I think disablenetwork can't be used. If we simply forbid use of
sendmsg() because application's code doesn't use UDP sockets, DNS requests (UDP
port 53) by libc's code cannot be handled and applications will stop working.
We must know what syscalls we need to allow when we forbid some syscalls.
* syscall numbers are architecture-dependent
* there are socketcall-style multiplexors (sys_ipc, anyone?)
* libc is free to substitute one for another
* libc is free to do so in arch-specific manner
* libc is free to do so in kernel-revision-specific manner
* libc is free to do so in libc-revision-specific manner
(... and does all of the above)
* new syscalls get added
* e.g. on sparc64 32bit task can issue 64bit syscalls
I don't mean to tell the kernel by "syscall numbers".
To be able to handle socketcall-style multiplexors, we will need a hook inside
each syscall functions.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Prev by Date: Re: RFC: disablenetwork facility. (v4)
- Next by Date: Re: [RFC PATCH] asynchronous page fault.
- Previous by thread: Re: RFC: disablenetwork facility. (v4)
- Next by thread: Re: RFC: disablenetwork facility. (v4)