From owner-freebsd-security Mon Jan 17 2:55: 0 2000 Delivered-To: freebsd-security@freebsd.org Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by hub.freebsd.org (Postfix) with ESMTP id 1DE9914C1A for ; Mon, 17 Jan 2000 02:54:53 -0800 (PST) (envelope-from d.m.pick@qmw.ac.uk) Received: from xi.css.qmw.ac.uk ([138.37.8.11]) by zeta.qmw.ac.uk with esmtp (Exim 3.02 #1) id 12A9mt-0000BB-00; Mon, 17 Jan 2000 10:53:32 +0000 Received: from cgaa180 by xi.css.qmw.ac.uk with local (Exim 1.92 #1) id 12A9mq-0007j9-00; Mon, 17 Jan 2000 10:53:28 +0000 X-Mailer: exmh version 2.0.2 2/24/98 To: Mark Newton , Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: Restructuring authorization checks to facilitate new security models In-reply-to: Your message of "Sat, 15 Jan 2000 16:13:34 +1030." <20000115161334.F767@atdot.dotat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jan 2000 10:53:28 +0000 From: David Pick Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoting Mark: > > The subject/object model looks reasonable, but I suspect that some > > operations will turn out to have more than one object operand; for > > example a user/process (subject) mounting (operation) a file system > > (object) at a particular place in the already mounted filesystem > > (second object). > > It strikes me that that example represents at least three separate > sequential authorization checks, not a single authorization check which > needs to work on three subjects. > > Not to say that other stronger examples mightn't exist, but this > doesn't appear to be one of them. Robert made a similar point; if you look at the question one way I'd agree: 1) is this subject allowed to mount this filesystem somewhere? 2) is this subject allowed to mount something at this point? but this doesn't allow for the question: 3) is this subject allowed to mount this filesystem at this point? because asking (1) and (2) separately doesn't allow for any permission relationship between the filesystem and the place where it is being mounted. Again, the relationship might be expressable as two separate relationships in an isoloated case but not if you want to allow a user to mount one filesystem in one place and another in another, but not the first filesystem in the second place or the second file system in the first place. There might be practical cases when the filesystems being mounted correspond to exchangeable devices in one case and fixed devices in the other. Other possibilities are the ability to attach specific serial devices to specific network interfaces especially when firewall rules are involved which specify different behavious on different network interfaces. Now, of course, if is possible to have composite "subject" or "object" "object"s which "point to" more than one "object", and then we can get back to binary relationships. If Robert's suggestions for using rather generic operations get used this will almost certainly be the case. I'm beginning to think (as I'm writing this!) that there might be two different answers to the question for the implementation and for the user/manager interfaces. Hmmmm......... -- David Pick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message