From owner-freebsd-hackers Mon May 20 11:46:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA07719 for hackers-outgoing; Mon, 20 May 1996 11:46:43 -0700 (PDT) Received: from orion.fa.tdktca.com (alex@[163.49.131.130]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA07712 for ; Mon, 20 May 1996 11:46:40 -0700 (PDT) Received: (from alex@localhost) by orion.fa.tdktca.com (8.6.12/8.6.9) id NAA31412; Mon, 20 May 1996 13:50:18 -0500 Date: Mon, 20 May 1996 13:50:18 -0500 Message-Id: <199605201850.NAA31412@orion.fa.tdktca.com> From: Alex Nash To: bde@zeta.org.au Cc: wollman@lcs.mit.edu, hackers@freebsd.org Subject: Re: unionfs Reply-to: alex@fa.tdktca.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > It should be possible for anyone to ask a trusted server to load > trusted LKMs. However, LKMs can't be loaded if securelevel > 0, > so it is best not to depend on loading them on demand. What a coincindence, I was just wondering if it was possible to load LKMs in secure mode just this morning (prompted by Garrett's IPFW concerns). Unfortunately I can't test this empirically with the FreeBSD systems here, so I've been looking through the code to see if this was allowed. As far as I can tell, the file system operations affected by securelevel are: /ufs/ufs/ufs_vnops.c: Check secure level when dealing with immutable and append only flags. /miscfs/specfs/spec_vnops.c: Do not allow opens for writing to disk character devices when securelevel is 2 or greater. Do not allow opens for writing of /dev/mem and /dev/kmem, or character devices that are currently mounted when secure level is 1 or greater. Do not allow opens for writing of any disk block devices when secure level is 2 or greater. Since modload opens a character device which is not a disk device, I don't think securelevel prevents LKMs from being loaded (but I agree that it should). What did I miss? Alex