From owner-freebsd-security Mon Oct 18 8: 2:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from fever.semiotek.com (H253.C225.tor.velocet.net [216.126.82.253]) by hub.freebsd.org (Postfix) with ESMTP id 4778F14BC2 for ; Mon, 18 Oct 1999 08:02:14 -0700 (PDT) (envelope-from jread@fever.semiotek.com) Received: (from jread@localhost) by fever.semiotek.com (8.9.3/8.9.3) id LAA03931; Mon, 18 Oct 1999 11:01:13 -0400 (EDT) (envelope-from jread) Date: Mon, 18 Oct 1999 11:01:13 -0400 From: Justin Wells To: Dag-Erling Smorgrav Cc: Justin Wells , Doug , Antoine Beaupre , Mike Nowlin , "Rashid N. Achilov" , freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X Message-ID: <19991018110113.A3888@semiotek.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK... but why was mount excepted in the first place? What I meant by "not confident that I understand all the different implications" is that I don't know what the reason for excluding mount was in the first place. Justin On Mon, Oct 18, 1999 at 10:56:51AM +0200, Dag-Erling Smorgrav wrote: > 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