[DGD] Idea for security system

[Steve Wooster]

     I've just had a bizarre idea for a security system, and I'd be 
interested in any comments/ideas/suggestions anybody might have. Feel free 
to tell me I'm smoking crack. :)

     In TMI for MudOS (maybe only an old version, I don't know), a possible 
security loophole is that if you have write access to a file, you can gain 
full access to anything that's granted to the UID of that file. For 
example, if an admin named Bob unwittingly gave you write access to 
/usr/Bob/open/ or something, any code you write in that directory has the 
user ID of "Bob". If Bob can write to root, your code could write a file 
with Root access that gives you full root access. Unfortunately, it's easy 
to forget about this loop-hole and give somebody write access to your 
directory without thinking.

     This gave me an odd idea for a security system where this might not be 
a problem... I'll try to go for a description that gives a basic idea of 
the concept rather than a list of all the details. Users aren't inherently 
a part of the system. Instead of granting file access to users, you grant 
it to directories (and in most mudlibs, each user would have a directory 
associated with themself). A directory has full RW access to all of its 
files and subdirs, but not to its parent directory. Any code has the same 
access as the directory it resides in.

     As an example of how this might be set up, imagine a mudlib with a 
user named Bob, and a domain or workgroup called EasternContinent. Bob 
works for EasternContinent. There might be directories called /usrs/Bob/ 
and /dmns/EastCont/. File access for /dmns/EastCont/ would be granted to 
/usrs/Bob/. The overlying mudlib would consider Bob to have access to 
anything that /usrs/Bob/ has access to, but the underlying file system has 
no idea of the existence of a user named Bob. There is nothing special 
about the directories /usrs/Bob/ or /dmns/EastCont/.

     Since access for /dmns/EastCont/ has been granted to /usrs/Bob/, any 
code in /usrs/Bob/ would have access to anything inside /dmns/EastCont/, 
but if Bob made /usrs/Bob/mystuff/somecode.c, somecode.c wouldn't have 
access to /dmns/EastCont/. However, Bob could grant /usrs/Bob/mystuff/ 
access to /usrs/Bob/ and/or /dmns/EastCont/, allowing somecode.c to access 
those directories. In fact, any code in /usrs/Bob/ (but not in any of its 
subdirs) would be capable of granting that access.

     If Bob granted /usrs/Bob/mystuff/ access for /dmns/EastCont/, then any 
code in /usrs/Bob/mystuff/ would be capable of granting access for 
/dmns/EastCont/ to any directory it wanted. However... (and this is a big 
however) if Bob removed /usrs/Bob/mystuff/'s access to /dmns/EastCont/, 
then all directories that had been granted access to /dmns/EastCont/ only 
through /usrs/Bob/mystuff/'s code would lose their access to /dmns/EastCont/.

     I figured that since something like this would require a bunch of 
CPU-intensive searching if it were full automated, what would instead be 
done is that you would list the access path something takes when you grant 
access. For example, when Bob wanted to grant /usrs/Bob/mystuff/ access to 
/dmns/EastCont/, he'd type something like:
grant ~/mystuff/ write to ~/ -> /dmns/EastCont/
That way, the mud would know that ~/mystuff/ could only have access to 
/dmns/EastCont/, if ~/mystuff/ had access to ~/, and ~/ had access to 
/dmns/EastCont/. Thus, the mud wouldn't have to search for everything that 
~/mystuff/ had access to, and everything those directories had access to, 
and so on... it could just rely on the users to know the best access path.

Similarly, imagine if there were users Bob, Joe, Bill and Jane. Bob has 
full access to Joe's directory, and Joe has full access to Bill's 
directory, and Bill has full access to Jane's directory. Bob could grant 
himself access to Jane's directory with the line:
grant ~/ write to ~Joe/ -> ~Bill/ -> ~Jane/
If the mudlib replaced usernames with their associated directories, Bob 
could type:
grant me write to Joe -> Bill -> Jane

I figure by making this an overt part of the system rather than an 
unobvious part, it's a bit harder to overlook it. Also, the fact that Joe 
could grant Bill full access to ~Joe/junk/ without having to worry about 
Bill being able to gain full access to ~Joe/ makes it a bit more secure.

So... is this idea worth fleshing out more, or am I on crack? (heh) :)
I'm thinking of maybe coding a simple version of it to give people a better 
idea of what it would be like.

-Steve Wooster

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd