Date: Mon, 18 Oct 1999 11:01:13 -0400 From: Justin Wells <jread@semiotek.com> To: Dag-Erling Smorgrav <des@flood.ping.uio.no> Cc: Justin Wells <jread@semiotek.com>, Doug <Doug@gorean.org>, Antoine Beaupre <beaupran@IRO.UMontreal.CA>, Mike Nowlin <mike@argos.org>, "Rashid N. Achilov" <shelton@sentry.granch.ru>, freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X Message-ID: <19991018110113.A3888@semiotek.com> In-Reply-To: <xzpso392gj0.fsf@flood.ping.uio.no> References: <XFMail.991015111802.shelton@sentry.granch.ru> <Pine.LNX.4.05.9910150036170.5339-100000@jason.argos.org> <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <xzpyad12jd7.fsf@flood.ping.uio.no> <19991018043039.B1711@semiotek.com> <xzpso392gj0.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jread@semiotek.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991018110113.A3888>