Steven M. Bellovin wrote:
> On Wed, 25 Oct 2006 08:21:35 -0700, Bill Studenmund <wrstuden@NetBSD.org>
> wrote:
> 
>> On Wed, Oct 25, 2006 at 09:11:50PM +0900, YAMAMOTO Takashi wrote:
>>>>> - why "share" rather than "export"?
>>>> I chose "share" because "export" is too tightly coupled with NFS. However, I'm
>>>> sure my point of view can be swayed ;-)
>>> it's actually tightly coupled with nfs, isn't it?
>>> eg. how can it prevent smbd or apache from exporting the filesystem?

I think if the issue behind this question is merely the name, it can be
changed. Ideally I suggested we use a more or less "generic" name for
the option, for perhaps future file-system support we may have. If it's
a serious issue (and apparently it is :) then I'm sure Matt won't have
trouble changing it.

>> We teach apache or smbd to look for it?

We probably don't want to do that.

> 
> Doing this strikes me as a really, really bad idea.
> 
> I agree that we need better permission semantics; I don't agree that this
> is the way to do it.  What I do and don't want accessible via NFS, Apache,
> Samba, and what have you has little or nothing to do with file system
> boundaries -- those, with rare exceptions, are artifacts of a particular
> set of system implementation choices.  It's only been, what, two years
> since the default NetBSD installation changed from the classic {/,/usr}
> model to a single file system model.  Does that mean that my security
> model has to change as well?

No; however, the topic of the thread was a mount option to use as a
strong reminder that a file-system shouldn't be exported. Look at the
implementation -- it's a real tiny code fragment to produce a "you
might wanna re-consider that". It doesn't even enforce removing the
"noshare" flag on securelevel 2 and above, etc.

For /tmp, usually mounted independently from / (or so I hope :), I
believe this flag is enough, if placed in /etc/fstab.

> The current discussion boils down, ultimately, to an implementation
> restriction in one of our file system types.  If someone were to put in
> the necessary code tomorrow, it shouldn't change what's being made
> available to outsiders.
> 
> What I really want, from a security perspective, is a way to say with high
> assurance "export this tree and that one over there, and nothing else".
> That's a very different requirement.

Do you have an idea on how to do that? where to store this policy?

-e.

-- 
Elad Efrat