Messages in this thread |  | | Date | Tue, 17 Dec 1996 20:21:37 +0000 (GMT) | From | Mark Hemment <> | Subject | Re: Authorization/Authentication Authority |
| |
Hi,
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
|  |