The events are automatically (it is part of the model) numbered, when they
are placed in the queue. Do you refer to timestamps?
> 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.
> >> 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.
> > 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.
> 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.
> 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.
> > 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...
> > Voila. the same read()! for the sake simpleness: take readv(), make
> > a special iovec with two elements: pointer to the syscall meta-data,
> > and pointer to the syscall arguments that points to wherever you what your
> > trustee's data to appear inside tracer. Pass this to the kernel, and it can
> > fill syscall meta-data, and do an mmap of the arguments if that's
> > necessary, or just copy_page() it. What you get is just one copy of
> > the meta-data (less than 1k, right) and (as you like) one or 0 copy
> > of the argument values. That's not much, isn't it?
>
> Now you are duplicating the entire system. Consider what happens when a user
> copies his directory tree to tape using tar... You copy the read... then you
> copy the write..., and with the users actual request you have 3 times the
> system load
It depends on what the tracer is supposed to do. Does it need to
examine the data, watermark it, or what? It does not make sense to
1.copy the data. 2.have any interest in it. in the context of
security application (that's as much as I know about security - you
tell me :-) Furthermore, I wonder how can you avoid
copying given you're explicitly interested in a copy not the data
itself...
> > 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.
> 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?
> -------------------------------------------------------------------------
> 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/
>
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/