Enforcing Permissions

[Donald L. Nash]

In article <8134 at phoenix.Princeton.EDU>, bernsten at phoenix.Princeton.EDU (Dan Bernstein) writes:
> There is a fundamental problem with UNIX security that alone prevents
> acceptance of UNIX at the B1 security classification or above: It is
> not possible to cure a security violation, only to prevent it. There
> is no way for a user to close a hole that is being used.
> [...]
> Fortunately, this problem is easy to solve, with a single added system
> call: enforce(char *name). Here name must be some item owned by the user
> in some namespace; enforce() re-checks all u areas of all processes for
> any violation of the *current* permissions on name, and revokes any
> permission that is not currently allowed. Note that the current working
> directory is one u area entry where enforce() cannot reasonably function.
                                                       ^^^^^^^^^^

Depends on your definition of "reasonable".  Have you ever tried the
following:

mkdir /tmp/foo
cd /tmp/foo
rmdir /tmp/foo
pwd

The results are interesting.  Since the reference count on the inode for
/tmp/foo is 1, the inode and disk blocks of the file are not freed.  However,
the link ".." is removed, so this directory is cut off from the rest of the
filesystem.  Many of your favorite system calls fail, so utilities like pwd,
ls, cd all start to behave very strangely.  The only way out is to cd to an
absolute path.  A similar thing could be done when your current directory
is enforce()'ed out from under you.  If you try to do some operation on the
current directory and you no longer have permission, then system calls just
start failing and the only way out may be to cd to an absolute pathname.

I don't know, but it sounds reasonable to me...


				Don Nash

				The University of Texas System
				Office of Telecommunication Services

SMTP:    dlnash at emx.utexas.edu, don at nic.the.net
BITNET:  DON at THENIC
UUCP:    ...!cs.utexas.edu!emx!dlnash