Date: Fri, 14 Jan 2000 08:46:35 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: freebsd-security@freebsd.org Subject: Further issues (was: Re: Restructuring authorization checks to facilitate new security models) Message-ID: <Pine.BSF.3.96.1000114083023.35781B-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.3.96.1000113200906.33318B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1000114083023.35781B-100000>