From owner-freebsd-security Sat Sep 18 19:40:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id 25BF814C4C for ; Sat, 18 Sep 1999 19:40:03 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from spawn.nectar.com (localhost [127.0.0.1]) by gw.nectar.com (Postfix) with ESMTP id 817FCBD05; Sat, 18 Sep 1999 21:41:25 -0500 (CDT) X-Mailer: exmh version 2.0.2 2/24/98 X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73 X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1 X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt From: Jacques Vidrine To: Wes Peters Cc: security@FreeBSD.ORG In-reply-to: <37E4449B.ADDD68EE@softweyr.com> References: <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <37E4449B.ADDD68EE@softweyr.com> Subject: Re: Real-time alarms Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Sep 1999 21:41:25 -0500 Message-Id: <19990919024125.817FCBD05@gw.nectar.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Here's a not-completely-thought-out idea. When looking at PHK's changes to suser for the jail code, I realized that he had essentially created two categories of suser calls in the kernel. One category of calls are allowed if you are NOT in a jail, and the other are allowed regardless of whether you are in a jail. I wanted to extend this so that each call to suser passes a category, kind of like we do with calls to malloc. I wanted to do this for two reasons: 1) finer granularity of control on what superuser priviledges a jailed process can use (specified at jail creation time) 2) auditing what superuser priviledges a process has used or tried to use e.g. SUSER_SIGNAL sent signals to process we don't own SUSER_RESOURCE changed our resource settings SUSER_KLD did something with a KLD SUSER_REBOOT rebooted the system SUSER_JAIL made a new jail etc. These categories could be as broad or specific as needed, although one per system call is probably too many :-) So if I'm running some server application that needs lots of root priviledges, I don't have to give away the farm.[1] Thoughts? Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org [1] for those who haven't looked at the jail code: it doesn't give away the farm, either. but the priviledges that can be used by a jailed process are ``hard wired'' and can't be customized. On 18 September 1999 at 20:04, Wes Peters wrote: > This is what we're talking about with the auditing facility. There are > a lot of architectural issues to be solved, starting with "what is an > alarm" and ending with "how do I securely transmit the alarms to those > who need to know about them"? > > Fun stuff, eh? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message