Date: Fri, 12 Jul 1996 14:46:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jim@starshine.org (Jim Dennis) Cc: terry@lambert.org, jim@starshine.org, igor@cs.ibank.ru, questions@freebsd.org Subject: Re: Samba FS planned to implement? Message-ID: <199607122146.OAA02075@phaeton.artisoft.com> In-Reply-To: <199607102347.QAA00222@starshine> from "Jim Dennis" at Jul 10, 96 04:47:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Further protections rely on typical obscurity mechanisms to interpose
> > a layer of protection to the mount point to enforce user access semantics;
> > even if this is instituted (which is not an enforced access method),
> > doing so on a per user basis requires a mount per user -- an unrealistic
> > administrative burden.
>
> In essence the Unix host running smbfs must be "trusted"
> by the admin of the SMB server (i.e. a problem of transitive
> trust)
Not exactly.
Each user the UNIX administrator trusts must be trusted by the SMB
administrator as much as the user the UNIX administrator uses to
establish the credential for the mount.
This falls through the cracks in both security models:
,------------.
| |
| | UNIX
| UNIX model | SMB
| | server
| |
`------------+-----------.
| |
SMBFS | SMB model |
| |
`-----------'
The "UNIX SMB server" model is a subset of the UNIX model, and so
can be mapped, though at a per access cost for the user credential
conversion, and with the need to compromise UNIX security by
giving out accounts to DOS users.
The other limitation is that security enforcement on UNIX is such
that there is no interface from the SMB client to set enforcement
restrictions -- they are settable only on the UNIX host (ie: you
can't set GID on a file from a DOS client).
This is acceptable, since it gives a minimal intersection of both
security models.
> This sounds like a design limitation rather than a "bug"
> per se. It limits the use of smbfs to single user workstations
> or to a limited number of "trusted" users per host -- and
> requires that the *ix system be reasonably secure and
> restrictive in its configuration.
Yes. However, the UNIX mount model is not prepared to deal with
this, and the credentials model is such that the SMB server
administrator may trust Bob the UNIX user, but not Tom the
UNIX administrator, with Bob the SMB user's files.
It is possible to cludge this by defining convoluted and complex
"here is how you use SMBFS" protocols which allow user maounts,
but it's "not UNIXy".
It's also unlikely that an annoying and cumbersome protocol will
obeyed when a wshortcut is possible. Look at all the DOS programs
which write screen memory directly instead of using the protocol
acceptable interface of INT 10.
> There shouldn't be a problem with "public" shares (those that
> are freely accessible within the domain) assuming that
> *both* machines in question are secure (on a private or secure
> LAN, possibly behind a firewall).
This is true. But how do you make the mounts *only* work on public
shares?
UNIX applications have limited utility in a "public share" where the
UNIX security model has been totally and completely compromised, and
you can not trust file contents, as a result.
We haven't even *discusses* resolving the interoperability problems
between UNIX advisory locking and DOS mandatory locking...
> A question:
>
> If someone is running telnetd on their NT box
> and allows multiple users on a LAN to telnet into it
> for shell (4NT or COMMAND) access .... does the same
> problem exist? Can that user see shares that the
> NT box has NET /USE'd? Can the NT admin also
> limit the access to those (similar to 'root' limiting
> the permissions on the smbfs mount point)?
I don't know; I have no real experience with the telnetd or shell on
the NT platform. I suspect that it could be guarded, since NT has
a user credential which can be referred to from the network client
in the NT IFS when a network request is made.
Probably, the user will be able to CD to the top level shares, may
be able to do a "dir" there (destroying security through obscruity for
the top level volume -- probably not a concern for a well-admistered
system), but will not be able to access inferior directories or files
for which an authenticated SMB version of his credential exists in the
password cache.
> Are you suggesting that this be implemented like CFS or
> userfs (I've used CFS but not userfs)?
No. I'm suggesting that the client security be implemented like the
Windows 95 password provider interface, where authenticating as a UNIX
user unlocks the users "password cache".
Then a session manager is established as part of login, and when the
kernel SMBFS needs a password for an SMB server, it asks the session
manager for it.
The session manager will look in the password cache, which the user can
use to establish pre-authentication information for when it is later
needed, and, if necessary and technically possible (ie: on the console
or an X sever or in a Screen session), the session manager can pop up
a user request to provide authentication information.
The information can be stored in the cache (at the user's option:
"remember this password"), and will be passed on to the kernel to allow
it to complete the pending request (or deny it, if the authentication
information is incorrect).
For systems that care about security of password caching, there is
always the ability to turn it off and have the session manager
query the user each time. This (l;ike the UnixWare NUC login)
assumes that there is a covert channel to the user -- UnixWare
assumes the ability to pop up an X requester from the session
manager.
Since UNIX cerdentials are identical for multiple sessions, it would
be a good idea to divorce the UNIX credential from the process. This
is a necessary step in B2/B1 certification in any case; however, it
is also possible to cache at the kernel level the credential/session
pair. Thus if a user has two xterms and attempts to access the same
network resource from each of them, he or she is only interrogated once
for verification.
This same method can be used, seperate from the user credential, to
provide directory and file level password protection in an FS stacking
layer (a B1 requirement).
This requires up-front session management implementation, but the
spin-off is well worth it (IMO).
I'm willing to work on the session management interface. I believe I
am one of the few people outside of Microsoft to have successfully
build a Windows95 password provider interface module.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607122146.OAA02075>