From owner-freebsd-arch Mon Oct 18 3:31:19 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 9022814BCF for ; Mon, 18 Oct 1999 03:31:14 -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 MAA15969 for ; Mon, 18 Oct 1999 12:31:13 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA76232 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 12:31:11 +0200 (MET DST) Received: from fticom.dipt.donetsk.ua (fticom.dipt.donetsk.ua [194.44.136.12]) by hub.freebsd.org (Postfix) with ESMTP id AA5CB14BCF for ; Mon, 18 Oct 1999 03:30:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from tkito.dipt.donetsk.ua (tkito.dipt.donetsk.ua [195.184.193.193]) by fticom.dipt.donetsk.ua with SMTP id NAA20521; Mon, 18 Oct 1999 13:30:52 +0300 (EEST) Received: (qmail 8297 invoked by uid 0); 18 Oct 1999 10:33:46 -0000 Received: from koi.pop.donbass.net by localhost with POP3 (fetchmail-5.0.0) for oleg@localhost (multi-drop); Mon, 18 Oct 1999 13:33:46 +0300 (EEST) Received: from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by fticom.dipt.donetsk.ua with ESMTP id MAA16338; Mon, 18 Oct 1999 12:10:43 +0300 (EEST) Received: by hub.freebsd.org (Postfix, from userid 538) id BBD0E14CB5; Mon, 18 Oct 1999 02:09:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 693F21CD472; Mon, 18 Oct 1999 02:09:28 -0700 (PDT) (envelope-from owner-freebsd-security) Received: by hub.freebsd.org (bulk_mailer v1.12); Mon, 18 Oct 1999 02:09:28 -0700 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 X-Loop: FreeBSD.org X-UIDL: f922d3e8b4e6bbb238663dff175180f9 X-Fetchmail-Warning: recipient address freebsd-security@freebsd.org didn't match any local name 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-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message