From owner-freebsd-security Mon Oct 18 1:57:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 97AD714CB5 for ; Mon, 18 Oct 1999 01:57:10 -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 KAA43413; Mon, 18 Oct 1999 10:56:51 +0200 (CEST) (envelope-from des) To: Justin Wells Cc: Doug , Antoine Beaupre , Mike Nowlin , "Rashid N. Achilov" , freebsd-security@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 10:56:51 +0200 In-Reply-To: Justin Wells's message of "Mon, 18 Oct 1999 04:30:39 -0400" Message-ID: Lines: 47 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin Wells writes: > On Mon, Oct 18, 1999 at 09:55:32AM +0200, Dag-Erling Smorgrav wrote: > > Well, then, fix mount(8) so it won't run at high securelevels. You > > know where to find the source code. > It's mount(2) that has to be fixed. I suppose I could go and look at > it, but I'm not confident that I understand all the different > implications of the securelevel stuff at that level. Here's an untested patch for -CURRENT which will make mount(2) fail with EPERM if running at securelevel 4 or higher. Took me all of three minutes to throw together. Index: vfs_syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.138 diff -u -r1.138 vfs_syscalls.c --- vfs_syscalls.c 1999/10/03 12:18:14 1.138 +++ vfs_syscalls.c 1999/10/18 08:52:56 @@ -123,6 +123,8 @@ if (usermount == 0 && (error = suser(p))) return (error); + if (securelevel > 3) + return (EPERM); /* * Do not allow NFS export by non-root users. */ 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); DES -- 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