scs@hstbme.mit.edu (Steve Summit) (09/25/89)
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.
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.)
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.
Steve Summit
scs@adam.pika.mit.edu
(alternate) scs@hstbme.mit.eduwlm@archet.UUCP (William L. Moran Jr.) (09/26/89)
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
jmsellens@watdragon.waterloo.edu (John M. Sellens) (09/26/89)
In article <14609@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >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. It occured to me a while ago that you can get most of the benefits of ACL's with group memberships. Write a program or two to create new groups when needed, make sure that a user can be in some reasonable number of groups, and you get most of what people are interested in with existing mechanisms. Note that you can have an exclusion mechanism by sticking the excludee's userids in a group, making the file that group, and denying permissions to that group.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/27/89)
In article <16687@watdragon.waterloo.edu> jmsellens@watdragon.waterloo.edu (John M. Sellens) writes:
-It occured to me a while ago that you can get most of the benefits
-of ACL's with group memberships. Write a program or two to create
-new groups when needed, make sure that a user can be in some reasonable
-number of groups, and you get most of what people are interested
-in with existing mechanisms. Note that you can have an exclusion
-mechanism by sticking the excludee's userids in a group, making the
-file that group, and denying permissions to that group.
This doesn't work, because the group-ID space isn't big enough for
every combination of access rights to have its own group (unless,
that is, your site has only a handful of users).sahayman@iuvax.cs.indiana.edu (Steve Hayman) (09/27/89)
In article <11154@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>John Sellens suggests writing a program to manage groups, creating >> new ones as needed, so that people can create their own groups. > >This doesn't work, because the group-ID space isn't big enough for >every combination of access rights to have its own group (unless, >that is, your site has only a handful of users). I don't think John meant that you'd have to have a group for every possible combination of users. A "group daemon" could hand out new group ID's as needed, recycle the old unused ones, and so on. Of course it would break down if people wanted to create a billion different groups, but in normal usage, I imagine most users would only need to create a few specialized groups. I might want to create one for me and you and John if we three were working on some project, but I wouldn't want or need to create groups containing me and all the other possible users. It'd be handy to have a group daemon so that I wouldn't have to bug the sysadmin every time I needed a special group. Steve Hayman -- Steve Hayman Workstation Manager Computer Science Department Indiana U. sahayman@iuvax.cs.indiana.edu (812) 855-6984
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/27/89)
sahayman@iuvax.cs.indiana.edu writes:
A "group daemon" could hand out new
group ID's as needed, recycle the old unused ones, and so on.
...It'd be
handy to have a group daemon so that I wouldn't have to bug
the sysadmin every time I needed a special group.
I did this late last year/early this year. I built a little tool
called "gred" (group editor) which allowed Joe Random User to edit
/etc/groups securely. It was mildly interesting to a few people, so I
wrote a short paper on it for summer Usenix, but it was rejected (such
is life, ohwell). It works quite well, but the real restriction is in
the number of groups to which a user may belong. The largest NGROUPS
I've found is on Pyramids, where it's 20; on Suns and similar things,
it's only 8. It's necessary to go to a bit of effort to knock NGROUPS
up and recompile everything that uses it, from the kernel up to such
mundane things as initgroups(3) and login(1).
--Karlflee@shire.cs.psu.edu (Felix Lee) (09/28/89)
In <14609@bloom-beacon.MIT.EDU>, Steve Summit <scs@adam.pika.mit.edu> 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. Scott Schwartz <schwartz@cs.psu.edu> has been randomly working on a daemon that implements access control lists. The idea is, if you want to open a file you don't normally have access to, you ask the daemon to open it for you, and it will give you an open file descriptor (after checking the access list). This can be extended to arbitrary file hooks, such as audit trails. Making this transparent is a matter of replacing open() (and recompiling everything in sight). -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!flee
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (09/28/89)
flee@shire.cs.psu.edu 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. Scott Schwartz <schwartz@cs.psu.edu> has been randomly working on a daemon that implements access control lists. The idea is, if you want to open a file you don't normally have access to, you ask the daemon to open it for you, and it will give you an open file descriptor This has already been done. See, for example, "Watchdogs: Extending the UNIX File System," by Brian N Bershad & C Brian Pinkerton, Winter 88 (Dallas) Usenix Proceedings (and a later version of the same paper in Vol 1 No 2 of _Computing_Systems_). --Karl
schwartz@psuvax1.cs.psu.edu (Scott Schwartz) (09/29/89)
Karl Kleinpaste writes: |flee@shire.cs.psu.edu writes: | daemon that implements access control lists. The idea is, if you want | to open a file you don't normally have access to, you ask the daemon | to open it for you, and it will give you an open file descriptor | This has already been done. See, for example, "Watchdogs: Extending | the UNIX File System," by Brian N Bershad & C Brian Pinkerton, Winter | 88 (Dallas) Usenix Proceedings (and a later version of the same paper | in Vol 1 No 2 of _Computing_Systems_). I've read it. What Felix was mentioning is nothing so ambitious. We just observed that you can make most filesystem requests via a (privileged) proxy, and let the proxy keep track of the access control lists. For things like read and write access, the whole thing can run in user mode, with no kernel modifications. A prototype only took a few hours to cobble together. (The downside is that if you really want all operations to be proxyable (like exec) you need to add a few things to the kernel.) -- Scott Schwartz <schwartz@shire.cs.psu.edu> for h in `cat /etc/hosts`; do telnet $h smtp; done; Now back to our regularly scheduled programming....