Date: Mon, 19 Mar 2001 23:00:18 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Sergey Babkin <babkin@bellatlantic.net> Cc: security@freebsd.org, Wes Peters <wes@softweyr.com>, fs@freebsd.org Subject: Re: about common group & user ID space (PR kern/14584) Message-ID: <Pine.NEB.3.96L.1010319223106.69303B-100000@fledge.watson.org> In-Reply-To: <3AB3FC38.94711FFF@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sergey, Sorry for my long delay in getting back to you with regards to your proposed changes. Let me start by saying I had a number of reactions at various levels (gut, technical, ...) and that one of the interesting aspects about the suggested changes is that they're remarkably self-consistent: most security "extensions" I've seen contain relatively easy-to-find inconsistencies that render them useless against a qualified attacker. My gut reaction to the changes is one of concern: it strikes me that while the changes have a number of nice properties (not least of which is the consistency of them, and that they don't require underlying file system changes), fundamentally there are a few objections that can be made. First, it's a hack, in that it will not be consistently applied across file systems, or even across boots depending on the kernel used. Second, it changes the semantics of well-defined interfaces and primitives such that they are more open than they used to be (a certain class of subject credentials will have a strict superset of the rights they previously had) without providing the application any way to determine if the feature is in effect (no pathconf(), so that leaves direct experimentation, etc). Third, your patches include no attempt to uniformly update documentation referring to users/groups to bring them in sync with the new implementation. Fourth, many applications exist that make strong assumptions about the UNIX protection mechanisms that will no longer hold true (this is related to (3), although not quite identical). Fifth, the resulting system is highly non-portable, in that neither users nor administrators with expectations from other systems (or even from FreeBSD) will be able to apply their knowledge and experience with the mechanism in place, and safety assumptions may no longer hold. Sixth, applications that assume that preserving permissions across certain types of file system operations will no longer behave correctly (for example, when you tar on UFS and untar on NFS). Seventh, it (as you point out explicitly, and by design) intersects two namespaces that have traditionally not been combined in the kernel. Userland code has often made assumptions about mapping uid and gid values, but that has never been a property of the kernel policy. Eighth, it introduces additional hard-coded uid/gid values into the kernel, something we've been trying to move away from (in theory, only two constant values should be relevant, leaving aside default device permissions: uid 0 and the uid used to represent NOVAL in vop_setattr() (which is evil also :-)). Now, none of these is a reason to completely reject the idea. In fact, there's precedent for conditionally compiled divergent security hacks in UFS, in the form of SUIDDIR, which adopts a modified file ownership/creation/inheritence model making for easier use of Samba on closed file servers (it represents a substantial security risk if not on a closee system). Ok, so that was the "gut reaction" and the "why the gut reaction doesn't rule out adding this feature". Let me go onto various other relevant responses. My first response on initial concern that this policy would introduce an "inconsistency". That is to say, based on this modified kernel policy and common uses of it in the userland policy environment, easily exploitable inconsistencies could be found and used to gain privilege. In my initial glance, I was unable to identify such an inconsistency -- that isn't to say it doesn't exist, just that on a quick initial analysis I didn't find one. Hence my comment above on this being relatively unusual :-). On determining that I didn't find any vulnerabilites off-hand, I was interested, as this is both unusual, and the changes bring some nice new system properties. As I said above, there is some precedent for this type of conditionally compiled feature (read: "hack"), and as long as it were clearly documented as such, my reaction is again not a rejection :-). I should take a moment also to respond to your comments on ACLs. In my view, they all apply. ACLs are a pain to deal with, because they increase the already high administrative overhead of managing per-file permissions. Personally, I'm a fan of the AFS ACL model, where protections are present only on directories, hard links are prohibited, and sub-directories inherit protections on creation. I even had an implementation of this on FreeBSD at one point, although it's quite dated now. However, ACLs have a number of things going for them: 1) They are portable. POSIX.1e pretty much defines everything you need to know (not quite) to implement a portable DAC mechanism. Many operating systems implement POSIX.1e with a high degree of compliance. Many applications know about, or are learning about, POSIX.1e. For example, Samba's new ACL support will speak POSIX.1e. 2) They provide compatibility with file modes: if you don't know about ACLs, all the mode commands "just work". This goes for users and for applications. You might not end up with the permissions you expect, but you'll end up with conservative and safe permissions according to the permission model. Applications and users won't make assumptions about UNIX mode compatibility and be wrong, failing open. The result was an even uglier ACL model, but the argument that this was desirable was a strong one. 3) They're widely used and fairly well inspected by a fair number of security types. So while I don't like POSIX.1e ACLs, I decided to implement them because these all seemed to be strong properties that were hard to ignore. Cutting "yet another discretionary access control mechanism" was really out of the question from these perspectives. In a few days, I'll be committing options UFS_ACL to the -CURRENT tree, and the result will be a fairly complete POSIX.1e/POSIX.2c implementation. Some userland tools, such as mv, cp, backup stuff, mtree, will need to be updated, and we have a few more bits of the ACL editing library to finish so as to support applications such as Samba. Other than to strongly caution against using your feature in most situations (especially where portability and safety involving multiple file systems, machines, operating systems, etc), I won't stop you from committing it (especially if you use it locally and with success). I will say that I think divergent and non-portable security models are likely to be more trouble than they are worth, and make my job substantially more complicated (we'll be starting work on a FreeBSD Security Architecture document at some point, and each time a random hack is added, we have to deal with the consequences :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" 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.1010319223106.69303B-100000>