From owner-freebsd-arch Mon Oct 18 2: 9:53 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 A8EF114D10 for ; Mon, 18 Oct 1999 02:09:46 -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 LAA14698 for ; Mon, 18 Oct 1999 11:09:44 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA75837 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 11:09:38 +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 B6EFC14BC3; Mon, 18 Oct 1999 02:09:23 -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 LAA43443; Mon, 18 Oct 1999 11:09:10 +0200 (CEST) (envelope-from des) To: Justin Wells 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> From: Dag-Erling Smorgrav Date: 18 Oct 1999 11:09:09 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "18 Oct 1999 10:56:51 +0200" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > 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'm thinking this might be -arch material. Do we want to do this? I think it can be done rather painlessly, and backwards compatibility with kern.securelevel should be easy to provide. The same mechanism can be used to implement process- or user-level capabilities, maybe leading us to merge (the hypothetical) sec_permitted() with suser(). After all, they're just two different ways of asking "is this ol' joe even *allowed* to do this?" DES (patches... must... write... patches...) -- 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