I was refering to the numbering - I just didn't realize that that was implied
by putting it on the queue. Some of the activity on the queue may be
asychronous -(see blow)
>
>
>> information to make a decision -
>> what process issued the write
>> which user is this
>> what is the users current security permissions
>> what are the current permissions on the file being written to
>> what is the parent process (log information)
>> when was the write started (log information)
>> when was it approved/disapproved (log information)
>> which event is being approved/disapproved
>>
>> For some security models you must also have access to information on
>> what other files may be open.
>
> It went without saying that all such information can be readily made
> accessible to the tracer.
As soon as the tracer needs the other information (assuming it must go
through /proc) then you get more events than you can process (recursion --
the tracer generates more I/O events gathering the other data since the
kernel can't tell if it is a security monitor doing it or a debugger)
Besides - you now have two more context switches (minimum) to get the
data. Using kmem may ease some of this, but then you have to deal with
possibility that some of the data is paged out.
>> >> The beauty of an approach like this is that it could be relatively generic.
>> >> Right now, in order to do this sort of thing with ptrace, you have to know
>> >> endless ugly details about exactly how to parse the stack, etc. This device,
>> >> though, could have a generic protocol.
>>
>> Generic maybe - but not complete. This is a technique more suitable to debugging
>> not security.
>
> What do you miss here? Is ptrace more suitable for security? I would
> argue that if something can support a mode of operation as subtle as
> debugging, it can support security as well.
I'm pointing out that the feedback loop in the reference monitor cannot keep
up with the data. Ptrace is also unsuitable for the same reason.
The reference monitor must be inside the kernel for the same reason that
the IP masquerade support is inside the kernel. Anything else is just too
slow. (consider trying to trace vi... every keystroke must be traced since
that is done with a read(fid,buf,1). vi also has to deal with escape sequences
that are time dependant (was that an esc key and not the uparrow key? It
depends on how soon that next character comes in, and what that character is)
>> > Indeed. read/write rules doesn't it ?
>>
>> Nope: ioctls are also used to read/write data (see the CD writer/reader for
>> examples)
>
> I'm aware of ioctls. And I think they should be banned. You don't
> need to ioctl the queue while it runs, that's what I meant.
ioctls can't be banned - They transfer data that is not suitable for
read/write. They are used to transfer control information. If no channel
for control information existed then a lot of devices would stop working.
>> nope: with multiple tracers you must synchronize the approvals. This requires
>> scanning the queue of not-yet-processed events to locate the event to approve
>> or disapprove.
>
> You don't have to scan it. When a request comes, some tracer is woken
> up and read() returns with the information about the call, after
> which another tracer can be woken up, if other request came by in
> the meantime...It all depends on the model. You can even have
> requests that needs to be authenticated by say, at least 10 tracers.
> In this case you can awake'em all, in specified order, and wait for
> 10 approvals. In either case, you know immediately which event
> requires processing.
This is when asynchronous handling of events occur and can cause problems:
want to try keeping lock synchronization coherent when the lock request/grant
is done out of order? (this could probably be handled, but handshaking
between processes becomes much slower).
>> batched yes - but not in a timely manner. There are too many events that have
>> some time coordination required - see audio recording/playback, CD writing,
>> RPC calls.
>
> There is tradeoff here between security and real-time.
hadn't even considered realtime - all that is desired is to read data
fast enough to keep an output buffer supplied with data. You can't do
realtime outside the kernel anyway. (UNICOS has been the only realtime
system fast enough - and that was only because of the 8-12 nsec cycle time.)
>> > 2. 1. + MP = definite speedup.
>>
>> speedup yes - but you end up having to dedicate a CPU to handling the tracer.
>
> is that a problem? I won't use this on my machine at home anyway...
I would because I have data that I don't want accessed from the internet
without using a fully encrypted line. I'm actually interested in using
it in a supercomputer center where security events occur at 100s per second.
That is too fast for such a slow method. The RSBAC project has already
done most of the hard work.
>> > ioctls have no play here. I am not sure what are you talking here
>> > about. What you do is just initialize this queueing externally "once" and never
>> > touch anything else but read() and write().
>>
>> again - ioctls do transfer data and control information (CD readers/writers)
>
> Ah, you want to trace ioctls? I thought that request bit in ioctl
> did encode stuff like r/w, device tag and the size of the argument. What
> prevents you from using that? If some IOCTL does not use this
> scheme, it should be considered UNSAFE even to trace it or execute
> it.
It depends on the nature of the device. Those that transfer data blocks
(CD writers) use the IOCTL because they have to issue control directives
to the device before the data can be sent to it. A read/write only interface
does not have the control information channel available.
Some interfaces (DATs for instance) have muliple modes of operation -
digital data in the traditional tape read/write; and audio data - now writing
track header information, timing information plus the audio data. Switching
a tape deck into audio mode could be disasterous if its done during a
backup (actually not possible since the ioctl file id must be open first,
but the sequence of events must not get out of order). ISDN modems can
have multiple modes too - consider a dual channel BRI connection. The
data path is 128Kbit (two 64K data channels), but the IOCTL interface
controls what is being done the rw stuff is only referring to the control
information.
>> This is more suitable to debugging security problems with a single application
>> that it is a generic security module. It is too slow.
>
> Your solution?
Put a rules evaluator in the kernel (see the RSBAC project since I think
that is how they did it, if not then I think this is better). The evaluator
does not have rules - it has the mechanism to implment rules. The rules
should be supplied from outside. Once the rules are loaded, they should
not be changed (single user mode required). If the audit log cannot be
completed then the system should shutdown to single user mode.
The best example I know of right now is how the IPSec RFC lays out
implemention guidelines. See the FreeS/WAN project for some details.
They are still developing their modules but it looks like a practical
approach that would be fast enough.
I can see the possiblity of having multiple rules evaluators (not
simultaneously). Each may be optimized for a particular security model.
It would be nice if it were a loadable module -- but it has been
pointed out that auditing the modules becomes another recursive problem.
I don't want to slow the system down more than 1-2% for the majority of
the security activity. Audit logging can be done in user mode since the
read-write activity is primarily aimed at batching up large number of
events per read-write (read the kernel supplied buffer, write to a file).
The reference monitors that I have had contact with do this just to
keep up. Cray systems can generate 17-20MB of audit activity per second -
we never turned on full auditing on a T3 (1048 processesors can generate
a LOT of data swamping nearly anything). A C90 generated 17MB in two
minutes of testing full login, data I/O access control, ioctl ...
Linux is becoming a mainframe capable OS.
-------------------------------------------------------------------------
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/