Subject: Re: NetBSD Security Advisory 2000-001
To: Chris G. Demetriou <>
From: Soren S. Jorvang <>
List: tech-security
Date: 02/16/2000 03:13:07
  by with SMTP; 16 Feb 2000 02:13:10 -0000
	by (8.9.1/8.9.1) id DAA20566;
	Wed, 16 Feb 2000 03:13:07 +0100 (CET)
Date: Wed, 16 Feb 2000 03:13:07 +0100
From: "Soren S. Jorvang" <>
To: "Chris G. Demetriou" <>
Subject: Re: NetBSD Security Advisory 2000-001
Message-ID: <>
References: <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <>; from on Tue, Feb 15, 2000 at 05:58:03PM -0800

On Tue, Feb 15, 2000 at 05:58:03PM -0800, Chris G. Demetriou wrote:
> "Soren S. Jorvang" <> writes:
> > > Well, I don't feel really confortable with this ... I'd prefer to have it
> > > restricted to root.
> > 
> > Very much seconded. No matter how hard we try, it will continue to
> > be a tricky issue.
> If it is, and is going to continue to be a security risk, then why do
> we ship it in default kernels at all?

I don't mean to say procfs or any of the other filesystems will
continue to be security risks (though they may well be), but that
allowing user mounts in general opens up lots and lots of
possibilities for holes that just wouldn't be threats without user
mounts, and while it may be possible to fix all filesystems, VFS
and the associated tools, even just identifying all the risks is
going to be hard.

Somewhat like 1777 /tmp, user mounts break a number of assumptions
and while some of those assumptions may even be unreasonable, it's
best to err on the side of caution. We are pretty much stuck with
1777 /tmp and people are very slowly fixing security in /tmp-using
programs. It seems to me that the similar potential issues for user
mounts were not fully considered when the feature was added and
since not many people are using it anyway, and amd works nicely for
the common application of mounting local removable media, it seems
wise to disable it with a sysctl by default, at least for now.