Date: Thu, 21 Oct 1999 08:41:28 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: hackers@freebsd.org, security@freebsd.org Subject: Re: Finer-grained securelevel: proof of concept Message-ID: <Pine.BSF.3.96.991021083426.46884A-100000@fledge.watson.org> In-Reply-To: <xzpiu41xgd6.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Oct 1999, Dag-Erling Smorgrav wrote: > Patches are available from http://www.freebsd.org/~des/. This is > strictly proof-of-concept; the patches demonstrate that fine-grained > security knobs can be implemented with minimal code impact. No > documentation is provided, RTFS. Very clean, pretty, etc -- only one object: please call it something other than capabilities :-). I already have a POSIX.1e kern_cap in the wings, and POSIX.1e has a very specific definition and interface for capabilities that refers to specific sets of rights, and is a per-process kind of thing. Maybe this is fgsecurelevel or something. To merge the two a little, I'd modifiable IS_CAPABLE() to accept a process as well as a description of the desired action, and because most of the ones (if not all) you've looked at are fairly infrequent, I'd be tempted to follow Eilvind's string-based hierarchal capability naming -- "kern.vfs.ffs.mount", "kern.socket.bind.tcp.25", "kern.socket.listen.tcp.25", et al. I believe he posted a missive on the topic on -arch a while back so it should be in the archives. BTW, it seems like what we really want is not securelevels, but some sort of Biba-like MAC integrity policy. I.e., stuff used during boot has high integrity, and the resources that can influence the high integrity component of the system should not be modifiable by lower integrity components except through specific and carefully monitored channels. I.e., each runlevel drops the integrity level of the initiating process by one level, meaning that new processes can never recover the old level, and therefore are prohibited from affecting the old level due to MAC. Disk devices, etc, would be marked as high integrity files on disk, so they would only be modifiable by very high integrity processes (Fsck, etc). Attaching a debugger to Init would be prohibited for normal processes, et al. 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-hackers" 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.991021083426.46884A-100000>