To: "Soren S. Jorvang" <soren@wheel.dk>
Cc: tech-security@netbsd.org
Subject: Re: NetBSD Security Advisory 2000-001
References: <14505.23693.773699.404104@passion.geek.com.au> <x6zot2w3h2.fsf@reddwarf.rightnowtech.com> <20000215230900.A6739@antioche.lip6.fr> <x6itzqw0di.fsf@reddwarf.rightnowtech.com> <20000215235049.A6841@antioche.lip6.fr> <20000215235639.B18825@gnyf.wheel.dk> <87g0utgb84.fsf@redmail.netbsd.org> <20000216031307.A20476@gnyf.wheel.dk>
From: cgd@netbsd.org (Chris G. Demetriou)
Date: 15 Feb 2000 18:36:31 -0800
In-Reply-To: "Soren S. Jorvang"'s message of Wed, 16 Feb 2000 03:13:07 +0100
Message-ID: <873dqtg9g0.fsf@redmail.netbsd.org>
Lines: 48

"Soren S. Jorvang" <soren@wheel.dk> writes:
> 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.

I think on this grounds (which is _not_ what I got from your previous
mail), it may be just fine to provide a sysctl which allows
administrators to diable user mounts.  However, it is a useful feature
and I still don't see a justification for defaulting it to 'off'.


> 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.

What kinds of assumptions are you talking about?  (surely, to make
this claim you must have some in mind!)


There are definitely some interesting issues that need to be thought
about when adding this type of feature.  My list goes something like:

(1) badly written file system code which, when presented with a bogus
file system will crash.  (not currently addressed except inasmuch as
most file system checks for UID right now.  Not addressable by using
AMD or another automounter or automated mounting tool.)

(2) device nodes, set-id programs, etc.  (all obviously fixable by
making sure that nosuid, nodev are set when mounting, and already
taken care of.)

(3) MNT_NOEXEC.  (handled by making sure that mounted FS MNT_NOEXEC
flag is set if moutned-on FS MNT_NOEXEC flag is set.)

(4) NFS exporting.  (a weird corner case because of the way mount is
done, but already considered.)
   



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.