From owner-freebsd-arch Mon Oct 18 7:50:10 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 18CAE14BDD for ; Mon, 18 Oct 1999 07:50:07 -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 QAA23649 for ; Mon, 18 Oct 1999 16:50:06 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA77798 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 16:50:06 +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 5BBBD14BC2 for ; Mon, 18 Oct 1999 07:49:14 -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 QAA44341; Mon, 18 Oct 1999 16:49:01 +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> From: Dag-Erling Smorgrav Date: 18 Oct 1999 16:49:00 +0200 In-Reply-To: Jacques Vidrine's message of "Mon, 18 Oct 1999 09:26:33 -0500" Message-ID: Lines: 52 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jacques Vidrine writes: > 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. With all due respect, *yuck* :) What EE suggested was to define a new SYSCTL macro to make defining new security sysctls trivial. You'd do something like this: static int sec_syscall_mount = 1; SYSCTL_SECURITY(mount, &sec_syscall_mount, "Allow mounting filesystems"); int mount(p, uap) /* ... */ { /* ... */ if (usermount == 0 && (error = suser(p))) return (error); if (sec_syscall_mount) return (EPERM); /* ... */ } This is *very* rough; I don't think I'd actually use an explicitly defined int like above; I'd rather use some kind of automagically- defined symbolic constant and a function call / macro for checking if it's set or not. This demonstrates the general idea, though; the rest is implementation details :) The sysctl knob would be named ``kern.security.mount'' or something, and be one-way; its initial value would be 1, and you'd be allowed to set it to 0 but not set it back to 1. The current sysctl_kern_securelevel() would be rewritten to twiddle the appropriate knobs, so that setting kern.securelevel would still have the expected effect. Going the other way (translating security settings into a meaningful kern.securelevel value) is not as trivial, though, so userland programs which rely on *checking* the value of kern.securelevel (as oppsoed to just *setting* it) may break. 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