Messages in this thread | | | Date | Fri, 19 Nov 1999 13:39:53 -0600 | From | Michael Elizabeth Chastain <> | Subject | Re: Linux needs flexible security |
| |
I know how to write a security monitor that does what you want: use ptrace. (Yeah, I know, ptrace is my one-trick pony.)
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/
| |