[lkml]   [1999]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux needs flexible 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)

    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? ;-)

    I'm really Look at 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.021 / U:78.196 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site