Messages in this thread | | | Date | Mon, 22 Nov 1999 22:10:16 +0100 | From | Pavel Machek <> | Subject | Re: Linux needs flexible security |
| |
Hi!
> > 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/
| |