why so? the tracer needs to use "more trusted" kernel counterparts
(operating on one security level lower than what it traces),
otherwize you do get potentially infitite recursion. this is just
like splitting sys_ guys into security-related part and the real
part that just does the real job. trusted applications (root is trusted)
can call unchecked parts directly. untrusted apps use untrusted sys_
calls, depending on the use case (trace, debug, watermark)
you can try to convince the kernel about your "clearance" at queue
fd initialization time, ie, when you open().
for different purposes, separate queues are maintained.
> 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
IP masquerade does not require that much flexibility.
> 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.
ioctl=read and ioctl=write, but then not on the filedescriptor,
but on the filedescriptor of the filedescriptor (semantics man).
every other usage of ioctl is a gross hack, in my opinion at least.
> 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).
agreed.
> > 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
thank god I have ISDN here :-)
> 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.
can't this be solved by adjusting the queue size to buffer the
mismatch (speed of the tracees/speed of the tracer)?
> > 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.
take SCSI generic. does it use IOCTL in order to forward both the
control and the data to the hardware? the point is that if you have
control then you have read/write as well...
> 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.
that is all very interesting, but ioctl still remains a gross hack.
> >> 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.
language interpreter in the kernel? I foresee viruses being finally
ported onto Linux Kernel Security Architecture :-)
> 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'll look at it.
> 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.
you have to make sure that your rules AND your evaluator are
safe: this defeats the principle of modules.
> 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).
one question. you said that if the log can not be completed, you
have to kill all running processes. what happens if your system is
really loaded and your log needs to get overwritten in order to keep
up. now, do you kill all processes? I can image this is a
possibility, but if you allow for the log to grow...
> 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 ...
Wow.
> Linux is becoming a mainframe capable OS.
:-)
Cheers,
pk.
/*****************************************************************
in a world without walls and borders who needs windows and gates ?
*****************************************************************/
-
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/