by mail.netbsd.org with SMTP; 15 Jun 2000 00:11:14 -0000
 via SMTP by mailo.vtcif.telstra.com.au, id smtpd0rVcSG; Thu Jun 15 10:09:36 2000
 via SMTP by localhost, id smtpd0yvF5E; Thu Jun 15 10:08:37 2000
          by balrog.supp.cpr.itg.telecom.com.au (8.8.4/8.8.4) with ESMTP
	  id KAA09271; Thu, 15 Jun 2000 10:08:36 +1000
Message-Id: <200006150008.KAA09271@balrog.supp.cpr.itg.telecom.com.au>
From: Simon Burge <simonb@netbsd.org>
To: tech-kern@netbsd.org
Cc: tech-security@netbsd.org
Subject: configurable disabling of kernel functions
Date: Thu, 15 Jun 2000 10:08:36 +1000

Un-fleshed out random idea time...

What if we had a mechanism that could disable certain kernel functions
from userland?  Obvious choices initially would be system calls,
filesystems and possibly sysctl nodes.  A case in point was the recent
semconfig problem, where we ended up making semconfig a dummy system
call, but people still needed to recompile kernels - sometimes it's not
convenient to do this right away for a number of reasons (kernel source
not at hand, long running simulation nearly finished, ra ra ra).  I
haven't thought too much about that the interface would be like, but something
like:

	sysctl -w security.syscall.semconfig = 0
	sysctl -w security.vfs.union = 0;

or

	sysconfig(XXX_SYSCALL, SYS_semconfig, DISABLE);
	sysconfig(XXX_FILESYSTEM, VT_UNION, DISABLE);

comes to mind (but with better names!).  We could even have an /etc/rc.d
script set some of these up on boot by parsing a /etc/system type file :)

Seriously, is this worth taking further?

Simon.