Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!bywater!acheron!archet!wlm From: wlm@archet.UUCP (William L. Moran Jr.) Newsgroups: comp.unix.wizards Subject: Re: File daemons (was: How do I detect who and when A file gets accessed ?) Message-ID: <303@archet.UUCP> Date: 26 Sep 89 05:41:32 GMT References:<14609@bloom-beacon.MIT.EDU> Reply-To: wlm@archet.UUCP (William L. Moran Jr.) Distribution: na Organization: A Desperate and Dedicated Crew Lines: 83 In article <14609@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >The obvious fully-general solution is to allow arbitrary >functions to be attached to files, to perform any kind of >authentication checking or audit trails that the file's owner >might desire. How much work (if any) has been done on >implementing such a scheme under Unix? Conventional Unix st_mode >permissions are usually found to be insufficient for doing really >seriously security-conscious work, but I have heard that some >"secure Unix" standardization effort or another has merely >adopted ACL's which, while obviously more flexible than 9 bits, >are essentially just more of the same, namely a static, tabular >representation of who can do what, without the radically greater >level of generality that an algorithmic permission option could >afford. > I actually have a 4.3 implementation of such a thing. It started as a more general implementation of ACLs, and I gradually added logging of accesses, lots of other bells and whistles, and finally the ability to specify some code which would decide who can access a particular file, and what happens when it is executed (tricks such as different things get executed by different people when they try /usr/local/bin/foo). Although I agree that this is more powerful than ACLs in theory, I've yet to figure out a really useful piece of code to attach as the authentication daemon (other than allowing password protection of files which is trivial and not too useful because it breaks normal filesystem semantics). Aside from the usual game time checker, what is a powerful and useful function to attach which does not seriously break 1k+1 other things? >There are certainly some questions to be answered about such >"file daemons:" who do they run as, the attempting accessor or >the file owner? (The latter, I think.) What per-file data can >the daemon function use? (It potentially needs arbitrary >storage, attached to the inode somehow, sort of like the file >contents itself but "out of band" with respect to it.) As far as the stuff I've done, the presence of an ACL, and the necessary stuff is pointed to out of the inode. There are several problems with this. First, it uses a space which is potentially unreclaimable if things go seriously wrong (although fsck could be modified to fix this). Second, there really isn't space in the inode (as I understand things) which the hacker is free to use (although I do anyway). I disagree that it potentially needs arbitrary storage; it - the stuff you call a "file daemon" - simply looks like a normal file to other people, and it protects itself. I think this solves the security problems since if you can break through one of these, it doesn't matter whether you do it to access the protector or the protectee. >Note that ACL's could be easily implemented under a "file daemon" >scheme (this is one indication of its superior generality): you >could write an ACL-checking daemon once, and attach it to any >file, storing the ACL itself in the per-file "out of band" data. > >I suspect that this is one of those areas where the extra >generality is expensive enough to implement, but needed in such a >small percentages of cases, that it usually isn't worth doing. Actually, allowing for the extra generality is really cheap. You simply have a flag which says whether there is an ACL, and another flag which says whether the ACL is provided or if code should be called. Unfortunately, when the code needs to be called, performance goes to hell, but the same is true of file logging. You can attach a log to all accesses of /dev/kmem *OUCH*. Anyway, at some point I'll finish the code to make this work right with NFS and release it. Bill Moran -- arpa: moran-william@cs.yale.edu or wlm@ibm.com uucp: uunet!bywater!acheron!archet!wlm or decvax!yale!moran-william ------------------------------------------------------------------------------- We had two bags of grass, seventy-five pellets of mescaline, five sheets of high-powered blotter acid, a salt-shaker half full of cocaine ... and also a quart of tequila, a quart of rum, a case of Budweiser, a pint of raw ether and two dozen amyls. ... The only thing that really worried me was the ether. Hunter Thompson