From owner-freebsd-security Mon Oct 18 7: 6:47 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 C4647150D8 for ; Mon, 18 Oct 1999 07:06:43 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from bone.nectar.com (bone.nectar.com [10.0.0.105]) by gw.nectar.com (Postfix) with ESMTP id 0FC34C008; Mon, 18 Oct 1999 09:06:38 -0500 (CDT) Received: from bone.nectar.com (localhost [127.0.0.1]) by bone.nectar.com (Postfix) with ESMTP id E32831DA3; Mon, 18 Oct 1999 09:06:40 -0500 (CDT) X-Mailer: exmh version 2.1.0 09/18/1999 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: Dag-Erling Smorgrav Cc: freebsd-security@FreeBSD.ORG In-reply-to: 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> Subject: Re: kern.securelevel and X Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Oct 1999 09:06:40 -0500 Message-Id: <19991018140640.E32831DA3@bone.nectar.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 18 October 1999 at 10:56, Dag-Erling Smorgrav wrote: [snip] > I'm starting to think that secure levels should be implemented as > bitmasks, with one bit for each operation or group of operation to be > allowed or denied (0 = allow, 1 = deny). The if statement above could > be rewritten as: > > if (securemask & SEC_MOUNT) > return (EPERM); > > Using a simple bitmask might be too simple though (it would restrict > us to 32 or 64 distinct operations), so we might want to hide the > actual implementation behind a function call or macro: > > if (!sec_permitted(SEC_MOUNT)) > return (EPERM); I've been thinking about something similar for suser, so that all uses of superuser privileges can be audited. For example, some hypothetical suser2 API that takes as one argument a constant specifying the category: int setuid(...) { ... error = suser2(p, SUSER_CREDS) ... } only for this to be truly useful, all calls to suser would have to be changed to suser2. This is the same kind of thing that DES is demonstrating above with the hypothetical sec_permitted. Chatting with DES on IRC, it seems to me that all this stuff (jail, auditing, securelevel) needs to fit together. Further, I feel like most (all) calls to suser or what have you in the top of the kernel could be covered if we made the granularity == syscall. This would break some abstraction, but if our hypothetical new suser or sec_permitted ``knew'' it was being called in the top of the kernel and ``knew'' what the current syscall was, our operations could just be table lookups. And especially for suser, we could tweak securelevel and jail stuff without having to modify the call to suser. -- Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message