Date: Tue, 26 Sep 2000 21:09:58 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: freebsd-fs@FreeBSD.org Cc: freebsd-arch@FreeBSD.org, trustedbsd-discuss@TrustedBSD.org Subject: VOP_ACCESS() and new VADMIN/VATTRIB? Message-ID: <Pine.NEB.3.96L.1000926203644.79897G-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
(sorry about flagrant cross-posting -- wanted to make sure that those with
interest would have the opportunity to comment)
In general, access control for operations within a file system is
determined via a recursive VOP_ACCESS() call on the vnode, vis.
VOP_OPEN(vp, ...) -> ufs_open(vp, ...) -> VOP_ACCESS(vp, ...) ->
ufs_access(vp, ...)
Flags are passed to VOP_ACCESS() indicating the specific requests being
made on the object, allowing VOP_ACCESS() to implement a variety of
discretionary and mandatory policies. VOP_ACCESS(9) documents these flags
as VREAD, VWRITE, and VEXEC, reflecting respectively read, write, and
execute rights. In recent changes to improve modularity and consistency,
Poul-Henning moved most of the mode/ownership-related components of
ufs_access() (and from other file systems) into vaccess(). File-system
specific components, such as the readonly status of the file system, and
UFS file flags, remain in ufs_access().
In the UFS code, VOP_ACCESS() is used fairly routinely to guard access to
the data associated with a file or directory. However, there is an
additional class of requests relating to file operations wherein checks of
inode attributes and characteristics are performed directly, rather than
falling back on the central VOP_ACCESS() implementation for the file
system. In general these requests relate to administrative actions for
the file: the ability to set protection rights for the file (ufs_chmod(),
ufs_chown(), and in the ACL implementation, also ufs_setacl()). As a
result, these access checks are scattered through the file system
implementation, and do not lend themselves to further generalization.
I ran into this problem while implementing mandatory access control for
FreeBSD: mandatory policies override rights that may be granted by
discretionary mechanisms (such as permissions and ACLs), allowing
effective partitioning and segregation of the system based on other
properties, such as sensitivity and integrity labels. One of example of
this is a Biba integrity policy, in which the permissions of a file might
allow write access to all users, but the MAC policy forbids this access as
it might violate system integrity (for example, incorrectly set
permissions on /kernel). Without generalized and centralized access
control for all access decisions, it is difficult to cleanly inserts more
flexible access control policies.
I'd like to propose that an existing VADMIN flag be added determining
whether or not the passed credentials are permitted to administer the
file. Here is a brief itemization of locations in the code where i->uid
checks would be replaced with VOP_ACCESS(vp, ... VADMIN ...) calls, with
some possible omissions:
File Use
ufs_lookup.c Allow owner of a sticky directory to delete any file in it
ufs_lookup.c Allow owner of a file to delete it from a sticky directory
ufs_vnops.c Allow owner of a file to set non-system file flags
ufs_vnops.c Allow owner to modify times on file
ufs_vnops.c Allow owner to modify permissions on file
ufs_vnops.c Allow owner to modify group of file
ufs_vnops.c Allow owner of a file or its parent directory to overwrite
that file if its parent directory is sticky
There are some other references to i_uid in ufs_vnops.c relating to the
QUOTA and SUIDDIR code. It is my belief, although I'd be glad to take
comments, that the QUOTA code should remain as is, as it's not for
access control but rather accounting. Similarly, the SUIDDIR code should
remain as is, as it has to do with whether or not the ownership on a newly
created file should be set to reflect the parent directory's ownership
instead of the calling credential.
The effect of this change would be to allow any rights granted via
ownership of a file but not in the VREAD, VWRITE, and VEXEC catagories to
the new VADMIN category. As a result, changes to the file system's
VOP_ACCESS() code could then grant or deny these requests based on other
factors in the credential, including mandatory policies. I selected the
name VADMIN based on a similar right in the Andrew File System (AFS),
"admin", which permits users or groups with admin rights for a directory
to manipulate its access control list. You could imagine adding a new
right such as this to the ACL implementation, although I have no plans to
do so at this point.
Robert N M Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000926203644.79897G-100000>