From owner-freebsd-arch Mon Oct 18 9:31:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7274614D50 for ; Mon, 18 Oct 1999 09:31:13 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA24860 for ; Mon, 18 Oct 1999 18:30:42 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA78346 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 18:30:41 +0200 (MET DST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 98D5B14E57 for ; Mon, 18 Oct 1999 09:30:26 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA44692; Mon, 18 Oct 1999 18:30:21 +0200 (CEST) (envelope-from des) To: Jacques Vidrine Cc: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018142633.D1DDB1DA3@bone.nectar.com> <19991018152147.609F71DA3@bone.nectar.com> From: Dag-Erling Smorgrav Date: 18 Oct 1999 18:30:20 +0200 In-Reply-To: Jacques Vidrine's message of "Mon, 18 Oct 1999 10:21:47 -0500" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jacques Vidrine writes: > On 18 October 1999 at 16:49, Dag-Erling Smorgrav wrote: > > What EE suggested was to define a new SYSCTL macro to make defining > > new security sysctls trivial. You'd do something like this: > [snip] > That's fine for system-wide stuff, but I'd like to see the ability > to tweak this same stuff per-process. Yes, I was coming to that 8) > I see a system-wide data > structure to hold this type of configuration information. Each process > should also have a pointer to the system-wide structure (or NULL) that > can be overridden by a system call such as jail. Or we could hang > this stuff off of the jail structure or something like it. Why are you so obsessed with jail(2)? There is no reason for this to be jail(2)-specific. As I told you on IRC: 03:21 #bsdcode Nectar> DES: securelevel == systemwide, jail == process based 03:22 #bsdcode ---------> nectar: no, you're not ambitious enough 8) What you want is process-level capabilities, which are inherited from parent to child. Init(8) starts out with all capabilities enabled; its child processes can then give up capabilities they do not need, but never gain any back. User-level capabilities can be implemented with relative ease by modifying setusercontext() et al. to tune capabilities according to login.conf. This is not entirely trivial to implement; one has to be very careful not to open huge security holes (by not revoking capabilities when one should). The safest path is probably to introduce a new syscall, e.g. setuid2(), which preserves capabilities, and have the legacy setuid() revoke *all* capabilities, so that programs which rely on setuid() to drop privileges will not suddenly become security liabilities. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message