> > 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)
Try it! strace vi 2> /dev/null gives good overview of that
situation. And yes it is nicely usable.
Worst-case slow down (and I mean worst-case) is 10 times. That is not
_that_ bad.
> >> > 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.
Ioctls should be banned. They make network transparent remote exec
hard, for example. Disabling all ioctls for user-level applications
should not hurt too much.... [clapity clap] Hmm, it will: console
operations are done using ioctls. Ok, disallowing ioctls is not possible.
> 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 ...
Who is expected to read such a huge ammount of logs? ;-)
Pavel
-- I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature, please!- 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/