>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/