Anil B. Somayaji wrote:
>Having said that, I don't think a completely general system-call
>interposition mechanism would be a good idea. It would definitely add
>significant overhead.
No, that's not the problem with syscall interposition. Try doing the
measurements. In all measurements I've done, if you do it right, the
performance overhead is essentially nil.
The reason not to use syscalls is because, for some tasks, they're at
the wrong level of abstraction. Consider the filesystem operations:
open(), and so on. Syscall interposition lets you filter on paths, but
we want to specify policies in terms of file-objects (inodes, really),
and translating between the two is much harder than you might think.
(Think: "..", symlinks, race conditions, and so on.)
Another reason not to use syscall interposition is that, in today's Linux
kernel, the mechanism is not easy to build without either (1) subjecting
yourself to race conditions (TOCTTOU bugs) or else (2) duplicating a
lot of argument-unmarshalling code in two places (and hence risking bugs
when the code gets out of sync, and making portability hard.)
The main reasons why people use syscall interposition today are that it
is possible to do today (easily, without terrible kernel hacking), and
that it allows to protect legacy apps transparently. But the project
undertaken by this list would make these reasons obsolete.
An additional reason to use the syscall interface for interposition is
that you can convince yourself easily that it is "complete": we can be
sure that we covered all security-relevant actions. This is a property
that seems more difficult to achieve with the alternatives, and we may
just have to live with the tradeoff.
A third reason is that syscall interposition is a crude, coarse tool.
That may sound like a disadvantage, but for some tasks, it's a feature,
not a bug. For instance, why should sendmail or any of its children
ever be allowed to call mknod(), mount(), *_module(), etc.? I don't
need to know what the pathname to mknod() is to know that I don't want
sendmail to be able to do it. But again this is another reason that I
suspect this project will make obsolete (if it is successful).
By the way, in case it's not obvious "how to do syscall interposition
right", here are a few tips:
- Replace entries in sys_call_table[] only for syscalls that
some module wants to interpose on.
- Don't interpose on read() or write(): interpose just on open().
Then you can leave those sys_call_table[] entries undisturbed,
and these syscalls will execute at full speed.
- For absolutely zero overhead for apps that aren't controlled
by a syscall-based module, extend ptrace().
Nonetheless, despite the possibility of doing syscall interposition
without terrible performance costs, I think that Linus is right that --
whereever possible -- we should try to find the "right" interface for
interposition, and syscalls are rarely the best interface.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:26 PDT