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>