The security monitor would be the parent process of the process that
you wish to control. It would use PTRACE_SYSCALL to run the target's
user-space instructions at full speed and filter the target's system
call requests. For example, if your httpd tries to open "/etc/passwd"
for reading, the security monitor simply logs the attempt, SIGKILL's
the process, whatever.
The idea behind this architecture is:
(1) A Unix process can do two things: it can execute a user-mode
instruction on its own memory map, or it can execute a system call
to do just about anything else.
(2) Your examples of security rules don't include any need to restrict
execution of user-mode instructions (Unix already has mature
mechanisms to control CPU usage). They also don't include any need
to restrict what the process does to its own memory (I don't know
why you would want that, or how you could do it!)
(3) In fact, all the interesting activity in your security rules is in
restricting the set of system calls which the process makes (e.g.
filtering the "open" system call and examining its arguments).
Lots of people know how to do this. Check out strace for an example.
Now imagine strace with a security-monitor-language built in.
The "... and my children part" is hard to do correctly in user space,
but it's possible, by tracking the fork() system call and capturing
the children. The hairy part is that the monitor winds up having to
implement all the wait4() logic on behalf of its children.
You could write this right now and it would work on existing kernels,
including the stable kernel series. The idea is also usable on other
versions of Unix.
Once you have a ptrace-based prototype, and you show that it is
functionally useful, then you could play around with kernel patches to
make it faster and more featureful.
For example, you could speed up this approach with a new enhanced
PTRACE_SYSCALL_WITH_MASK that takes an N-element bitmask of the system
calls which cause traps to the parent. This would enable you to monitor
with very low overhead, as all the gettimeofday() and sigaction() calls
would run at nearly full speed: a few more instructions per system call,
with no extra context switches.
In fact, have another look at your examples. You want to write your
complex security rules for calls like "open" and "connect". You don't
care about monitoring "read" and "write"; your security gate is at the
"open" call, just as it is for Unix security.
So I think that this architecture:
(1) can be made to work today in user space
(2) keeps all the complicated rules in user space
(3) enables logging with logging mechanisms in user space
(4) with a simple mechanism-only kernel patch, this architecture
can run about as fast as any possible solution that keeps
the complicated rules in user space
Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/