OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
FreeBSD Security Archives: Re: kern.securelevel and X

Re: kern.securelevel and X


Dag-Erling Smorgrav (desflood.ping.uio.no)
18 Oct 1999 10:56:51 +0200


Justin Wells <jreadsemiotek.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 - desflood.ping.uio.no

To Unsubscribe: send mail to majordomoFreeBSD.org with "unsubscribe freebsd-security" in the body of the message



This archive was generated by hypermail 2.0b3 on Mon Oct 18 1999 - 03:57:58 CDT