On Fri, 13 Dec 1996, LD Landis wrote:
> In a recent issue of UNIX Review (which I can't find right now, grrr, but
> it was this fall, I think), there was an article about what it would take
> to make UNIX a "well behaved" entity relative to security, etc. The
> model with which the conventional "UNIX Security Model" was contrasted
> was, of course, that of IBM MVS (where access questions are answered by
> a separate autonomous entity).
>
> Now, having hacked kernel stuff from time to time, and also having to be
> sure to "do the right thing" (relative to security)... and given the
> current state of Linux (very good, IMO)... I've been thinking lately...
>
> What is the likelihood of separating out the authentication/authorization,
> security, etc, etc, etc according to such a scheme? It seems to me that
> this would be relatively straight forward, given the current facilities
> in Linux, and would be a real win for those needing "advanced" features.
I once tried a little hack out on an old box, which was based on
something I read about SVR4 watchdogs (Note, not the same as Alans'
watchdogs).
A watchdog is a user-level (root) process that registers its
interests in certain events assoicated with certain files and/or directories.
It could register; for a simple notification of an event, that it would
"authorise" an event, or would modify an event (eg. modify the data from
a read/write).
The idea was to provide;
o User-level accouting associated with certain files
o User-level authentication to certain files/events
o Automatic compress/decompression/encoding/decoding of read/writes
to certain files.
o Simulation of files by having watchdogs on directories.
o Notifications to GUI applications so when a directory they are
displaying changes.
Basically, the hack involved introducing an extra indirection into the
function ptrs for the operations on an opened "struct file". If a file
was marked as having a watchdog then, when it was opened, the original
function ptrs where saved and new ones installed.
Any operations on the file would then call the new functions, which would
pass a message to a user-space watchdog process before calling the
original file function. A watchdog could register what events it wished
to received, and whether it would "authorise" the event (ie. the function
had to wait for a response). Only events which were of interest to a
watchdog would go through an indirection function (to help performance).
Needless to say, I was being over ambitious. I never created a proper
message passing system, for the events and data, from the kernel to a
watchdog. A watchdog simply registered an interest in a file by opening
it, and sending an ioctl() on the opened file descriptor. It would then
receive ioctl's on events, and could respond (when necessary) with ioctls.
Any data which had to be read/written used the same file descriptor.
The main problems were;
o The lack of a decent communication channel (and poor time-out
waiting for a response from a 'hung' dog).
o The difficulty in maintaining enough state for some of the
operations (simulating a file, and modiying the data a user
process saw in a file).
o Just redirecting the file operations were not sufficient, redirection
of inode operations were need as well.
o Loads more....
I believe I had the right idea. I justed stated coding before thinking!
I'm not saying watchdogs are an alternative to ACLs and privilages, but
they would give a solution to a few files requiring special 'security'
considerations.
If anyone is interested in running with this idea, send me a message and
I'll see what source I can find.
Regards,
markhe