Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!spool.mu.edu!usenet.eel.ufl.edu!bofh.dot!hookup!lll-winken.llnl.gov!enews.sgi.com!sgigate.sgi.com!uhog.mit.edu!news.mathworks.com!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Can FreeBSD mount Netbeui volumes?
Date: Thu, 16 May 1996 17:40:59 -0700
Organization: Me
Lines: 142
Message-ID: <319BCB1B.2FC654BE@lambert.org>
References: <postmaster-0905961001120001@206.65.200.5> <319404CD.33E93F68@lambert.org> <4n1urr$rjj@uriah.heep.sax.de> <31950D9C.15C6228A@lambert.org> <4nbnt0$ndo@Mercury.mcs.com>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Leslie Mikesell wrote:
] In article <31950D9C.15C6228A@lambert.org>,
] Terry Lambert <terry@lambert.org> wrote:
]
> >But the security model in BSD (and UNIX, in general) needs to
] >change for it to be practical for anything but single user
] >machines not offering authentication services (telnet/rlogin/ftp/
] >http/gopher/nfs/etc.).
]
] I disagree.
] (a) Authentication is up to the whim of the person who
] knows the root password on any unix machine (at least if
] you are relying on uid's reported by that machine). If you
] don't trust the root user to treat resources appropriately you
] shouldn't let that machine have access. If you do trust
] the root user, then you should let him protect the mount
] points appropriately.
Good theory. It would even be right if the SMB and NetWare
servers would allow your machines "root" to vouchsafe local
credentials to the server (ie: UNIX user "terry" should be
treated as SMB user "terry" by the SMB server).
Given the current model (SMB tag credentails to a session
instead of to a packet like NFS), you *will* lose user level
access control management if you allow SMB shares.
] (b) We may be talking about WFWG servers here which don't
] have much in the way of user concepts.
We are talking about the SMB (NetBEUI) authentication model;
the subject implies NetBEUI, but the questions from the
original poster make it clear that they meant "wire protocol"
(SMB), not "transport protocol" (NetBEUI).
WFWG server or not has nothing to do with it.
] (c) Fully shared access to files may be appropriate for
] certain uses.
Yes. I already agreed with this. Certain, atypical, non-common
case uses, for which it would be impossible to prevent people
from mistaking them for common-case uses (rule of "least
astonishment"), and screwing their security all to heck.
] >] However, the security considerations are to be taken serious.
] >] I could however think of a model where an SMB file system can
] >] be used to access all the services marked `public'.
] >
] >You could, but it redefines public from meaning "accessable to
] >any authenticated user" to meaning "accessable to any user,
] >authenticated or not".
]
] Only if the authenticated root user on the remote machine decides
] to make it so.
NT machines don't have "root" users.
Are you (mistakenly) under the impression that the UNIX user
ID from a client machine making a request will be available
to the server machine simply because the server machine is
also a UNIX box?
This is not the way that SMB and NetWare authentication work.
The work by associating a user credential with a connection;
NFS operates by associating a system credential with a connection
and passing the user credential in the requests that are made.
The difference is that there is no "user ID" field in SMB and
NetWare packets for the server to use to verify credentials on
a per user basis.
The credential is *only* available when the connection is
established, and *must* be presented when this occurs, meaning
a one-connection-per-user requirement exists.
] >Because the UNIX box would authenticate once and could
] >credential gateway by proxy any user from the internet or
] >dialup lines onto the thing. Which violates the credential
] >model in SMB (which doesn't support the concept "proxy").
]
] Yes, that may be what you want. If it isn't don't make
] the mount point accessable to anyone else.
However, if this *is* what you want, you are in the minority.
The majority, on the other hand, don't realize that they would
be laying their systems open using this option. They would
either find it unusable (if they realized it) or mistakenly
use it, believing that they have user level credential
enforcement (which you just killed with your design).
] >Any time you start permitting proxy when "emulating" a DOS
] >client to a network server (LANMan, NetWare, ATP, etc.), you
] >break security.
]
] But servers that rely on client politeness already have broken
] security.
Says you.
] Are you suggesting that operating systems should omit all
] features that have the potential to be misused?
No. I'm saying that somone needs to write ~10,000 lines of
code (minimum) before an SMB client FS could be considered
a feature instead of a back door.
This problem *IS* solvable. It's just not solvable the way
you apparently think it is.
This problem two nealy 20 man-years to resolve in the NUC
(NetWare UNIX Client) code from Novell. I don't see you
resolving the credential dichotomy any time soon.
If you think it's already resolved, then we should move on
to discussing DOS server implementation of mandatory file
range locking vs. UNIX client implementation of only advisory
range locking, and how the two interact.
Solving the problem requires more effort than hand waving and
saying "all's ya gotta do...".
Feel free to write your own SMBFS code an "prove me wrong".
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.