Messages in this thread | | | Date | Sat, 20 Nov 1999 09:20:39 -0600 (CST) | From | Jesse Pollard <> | Subject | Re: Linux needs flexible security |
| |
From: Michael Elizabeth Chastain <mec@shout.net>
>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.
Unfortunately - this looks like it would require a monitor per process, and what happens to processes using the ptrace for debugging?
It also can't be validated to catch all the activity (This is from the perspective of a user of multi-level security systems). It is necessary for ALL processes to be tracked - even init (after auditing is turned on). Think about attempting to track inetd for instance - it may be recieving 10s to 100s of connections per second. Also consider tracking RPC functions, the portmapper/nfs does recieve 100s of connections per second. I don't think a ptrace approach could handle the kernel nfs anyway. A ptrace implementation could only be used for early prototyping - which has already been done by the RSBAC project (the prototyping, that is).
Auditing is not a simple user-space activity. It requires too many traces - not just fork, exec, read, write but also shared memory, vforks, exit ioctl ... For this large number of items it becomes necessary to have a security monitor that is between user-space and implementation of the syscall. It doesn't have to be very large unless the event is being tracked. The test should only be a bit vector test - 5-10 instructions or so. The tracking activity might be more combersome - the most detailed would duplicate all the parameters and data for the event and pass it to a logging queue (I wouldn't recommend doing this of course, it is the worst case, and besides - how would you log the shared memory accesses..)
>... >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.
Enforcement requires read and write observation too (all under a configuration control). A file may change its security state while another process has it open. This terminates a read with a permissions error if the file has access denied - this is not in the current UNIX security design, although it is not prohibited from being implemented either, just more overhead that is not normally needed.
>... > (2) keeps all the complicated rules in user space
As for the rules in the kernel - there is no other place for them to be evaluated. There isn't enough time to make a full context switch to reach a reference monitor to evalutate them for each security event.
This is equivalent to the activity being put together in the FreeS/WAN project for TCP/IP security. It is also the same as for the IP masquerading - the rules ARE in the kernel. Establishing the rules, however, is done in user space. Only (the reference monitor of) the kernel can enforce the rules. And the rules don't appear to be as complicated as the IPSec rules can be.
Personally, I would like to have the RSBAC project (or it's equivalent) accepted as a portion of the kernel, to be maintained in the same way as the rest of the kernel. I would also like to have the FreeS/WAN project also supported in the same kernel (I know, the encryption export rules still prevent this).
MLS has become a rather broad subject now that common criteria has become the "standard" definition. The RSBAC project appears to have approached it with the intention of allowing whatever rules (and in some sense, security models) to be altered by local requirements. I see this as a good thing, especially now that Linux is running on large, multi-cpu, systems. I am expecting to see Linux on a 256 node SGI O2K (or a Sun E1000) in the next couple of years and would like to be able to use it in a secure environment.
The normal UNIX security is more like "anything not prohibited is allowed", which makes it difficult to identify what should be prohibited. The MLS approach is closer to "anything not explicitly permitted is prohibited", which is easier to evaluate, and helps prevent security oversights. ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- 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/
| |