Date: Wed, 27 Sep 2000 08:53:06 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Terry Lambert <tlambert@primenet.com> Cc: Julian Elischer <julian@elischer.org>, freebsd-fs@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG, trustedbsd-discuss@TrustedBSD.org Subject: Re: VOP_ACCESS() and new VADMIN/VATTRIB? Message-ID: <Pine.NEB.3.96L.1000927083240.88777C-100000@fledge.watson.org> In-Reply-To: <200009270723.AAA20257@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Sep 2000, Terry Lambert wrote: > Perhaps a better question would be "assuming you generalize > the references cited using the orioised VADMIN, how many > references not using VOP_ACCES() will remain?". My goal was to identify the application of ownership righs on files and directories (i.e., rights not granted by the discretionary permission maks of ACL). As it turns out, this class of checks maps extremely well into the current use of ip-i_uid in the src/sys/ufs/ufs tree, resulting in very few remaining references. As I refered to, the remaining references generally fall into two categories: first, the quota code which uses the file uid to determine how to account for use (index into dqget()), to determine when it should or should not report quota limit problems (uprintf() to warn of quota conditions), and to determine whether the current credential cr_uid matches the owner of the parent directory of a newly created file when SUIDDIR is enabled. In general, these are not access control decisions, rather strict use of the cr_uid as an identifier, meaning that abstraction of VADMIN as a category successfully removes all remaining uid-based authorization code in UFS. > I think the generalization and centralization which took > place are really bad things, since I think administrative > policy is something that I may very well want to set on > _both_ a system basis _and_ on a per-FS basis. I think there are both reasonable arguments for and against the generalization in vaccess(). One important advantage of the generalization is that it reduces the number of instances of permission-based authorization checks, allowing easier auditing and modification of the policy. For example, when I introduced support for POSIX.1e capabilities in my source tree, I needed only replace one instance of suser() rather than dozens scattered through the source tree. It also makes it easier to audit the use of privilege for correctness and logging purposes if it can be centrally identified. There is probably a decent argument that vaccess(), while a good idea, does not have an API lending itself to future expansion and flexibility: it directly accepts file uid, gid, and mode fields, and does not have a policy-related argument that could be used by the caller to specify how centralized checking should apply in the context of the current file system. > I also think that read-only-ness of an FS is a mount > option having nothing to do with the underlying FS itself. However, I think it is also arguable that the read-only-ness of a file system is not a security property, but in some cases a media property. That is to say, some file systems should be read-only by virtue of the underlying storage medium or file system type. Often, file systems are mounted read-only for security reasons, which is "different". vaccess() abstracts only the generalized security decision, not determination of per-file system or per-mount options. I think it would be reasonable to argue that we should attempt to distinguish security and non-security mount options, and provide the file system an opportunity to pass the security mount options to generalized security checking code, and that the current single read-only flag does not distinguish the security and file system properties that might be desirable. That said, I think there's also an argument that you would only process the read-only property centrally if you were willing to allow super-user privilege to override that protection. I.e., vaccess() performs discretionary and mandatory access checks, with privilege allowing the overriding of those protections. If the protections should not be overriden by appropriate privilege, they should not be processed as security protections in vacess(), which would further distinguish read-only mounting and a read-only security status. > It seems to me that some of the centralization should, in > fact, be backed out, since it seems that it would preclude > layer recursion in some useful stacking arrangements, much > in the same was a non-NULL VOP did when the "default" layer > was introduced (with no mechanism to provide default > semantics for nely defined VOPs, without a kernel recompile). I'm not sure I follow this argument. Each file system's VOP_ACCESS() implementation invokes vaccess() based on arguments it provides, and only if it chooses. For example, only file systems making use of a per-file uid/gid/mode currently invoke vaccess(). Coda does not invoke it, and in my ACLs tree, UFS doesn't invoke it, instead, vaccess_acl() in kern_acl.c. vaccess() is not a default VOP, rather, a helper function for VOP_ACCESS() implementations with common security properties. VOP_ACCESS() -> ufs_access() -> vaccess() Given this description, do you believe there would be limits imposed on stacked file system support? 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.1000927083240.88777C-100000>