From owner-freebsd-security Fri Nov 26 7:21:30 1999 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 A365815060 for ; Fri, 26 Nov 1999 07:21:20 -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 KAA50821; Fri, 26 Nov 1999 10:21:17 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Fri, 26 Nov 1999 10:21:17 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: David Wolfskill Cc: security@FreeBSD.ORG Subject: Re: ps on 4.0-current In-Reply-To: <199911241622.IAA25297@pau-amma.whistle.com> 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 On Wed, 24 Nov 1999, David Wolfskill wrote: > >Oh for ACL's, privilige attributes, etc. It would solve this sort of thing > >nicely so that you could allow admin users to see what's going on > >(including a ps -ax and see what the users are running) without having to > >constantly (ab)use root and the dangers of overusing that. > > True, though it would seem that allowing certain capabilities based on > membership in some (set of) group(s) could help just enough to get by -- > that is, so that the lack of the ACLs &c. never gets quite so painful > that someone gets around to writing code to fix it. :-{ The painful thing is getting ACLs into the underlying storage mechanism, not writing kernel ACL support -- I've finished the framework in the kernel, libraries, some userland utilities, and even default evaluation routines for file systems to call. I just don't want to screw around with FFS storage and soft updates :-). Given my current code, it would be easy to extend procfs to use the ACL support -- right now all file systems return EOPNOTSUPP for vop_getacl and vop_setacl, but you could easily tie a struct acl to the pnodes in procfs and set the default ACL on /proc in /etc/rc.something -- all children could inherit that ACL and the permissions would be set correctly (i.e., u::rwx, g:operator:rx, etc). I'll tar up my existing ACL code and make it available sometime this evening -- it'll be downloadable from http://www.watson.org/fbsd-hardening/posix1e/acl currently not useful for anyone but someone wanting to modify file systems to support ACLs :-) Also, it's modulo 3.3-RELEASE as 4.0-CURRENT was way too unstable when I started work. 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