From owner-freebsd-security Fri Jan 14 5:49:12 2000 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 28AE0151A0 for ; Fri, 14 Jan 2000 05:49:05 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id IAA36057 for ; Fri, 14 Jan 2000 08:46:35 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Fri, 14 Jan 2000 08:46:35 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-security@freebsd.org Subject: Further issues (was: Re: Restructuring authorization checks to facilitate new security models) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A further expansion on a question I meant to address in my previous email, but didn't go into in detail: Should type information for objects/subjects be passed as a property of the object/subject argument components, or as a property of the operation component? I.e., ACCESS_PKILL implies that both elements are processes, but you could imagine using more generic ACCESS_WRITE and providing type information to indicate that the elements are processes. I.e., int access_check(subject_type, subject_label, object_type, object_label, operation_descriptor); In this manner, modules could determine whether they are interested in mediating a particular request--i.e., a prison implementation could decide to ignore all file requests, as chroot would cover its requirements. This could result in a reduced set of operations that are easier to manage: i.e., ACCESS_READ, ACCESS_WRITE, ACCESS_ALLOC, ACCESS_DELETE, and so on, allowing more overlap between categories based on subject/object type. The nature of the operation_descriptor field is pretty relevant--do access control mechanisms wants to make decisions based on well-defined abstractions, or based on specific call descriptors (i.e., per-syscall/vnops/vfsops/etc)? Or both? Possible object_type's might be: OBJECT_IPFW OBJECT_VNODE OBJECT_PROC OBJECT_KERNLINKER ... You could also imagine a two-level hierarchy for the operations as a possibility, with flags indicating specifics if necessary: ..., REQUEST_TYPE_VNODE, REQUEST_OPEN, FWRITE|FREAD) ..., REQUEST_TYPE_IPFW, REQUEST_READ, 0) ..., REQUEST_TYPE_PTRACE, REQUEST_OPEN, 0) ..., REQUEST_TYPE_IP_TCP_PRIVILEGED, REQUEST_OPEN, 0) or ..., OBJECT_VNODE, REQUEST_OPEN, FWRITE|FREAD) ..., OBJECT_PTRACE, REQUEST_OPEN, 0) ..., OBJECT_SOCKET_IP, REQUEST_OPEN, SRESERVED) Depending on how fine-grained the mechanism needed to be, this might have to be very detailed, or fairly broad. Keeping a standard REQUEST_ field would allow decisions about operations that might not be understood by the policy mechanism--i.e., MAC might not know about vnodes, but would know that a process with an appropriate label might be permitted to read but not write that object, suggesting REQUEST_OPEN should in fact be two calls at open time--request permission to READ, and optionally WRITE if vn_open() wanted it. Similarly, signalling might constitute a WRITE from the point of view of MAC, suggesting: ..., OBJECT_PROC, PROC_SIGNAL, REQUEST_WRITE, 0) ..., OBJECT_PROC, PROC_PTRACE, REQUEST_WRITE, 0) Anyhow, thoughts are welcome. Depending on response on -security, I may move this to -arch in a bit. 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-security" in the body of the message