From owner-freebsd-questions Fri Jul 12 14:53:53 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA20823 for questions-outgoing; Fri, 12 Jul 1996 14:53:53 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA20815 for ; Fri, 12 Jul 1996 14:53:47 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02075; Fri, 12 Jul 1996 14:46:25 -0700 From: Terry Lambert Message-Id: <199607122146.OAA02075@phaeton.artisoft.com> Subject: Re: Samba FS planned to implement? To: jim@starshine.org (Jim Dennis) Date: Fri, 12 Jul 1996 14:46:25 -0700 (MST) Cc: terry@lambert.org, jim@starshine.org, igor@cs.ibank.ru, questions@freebsd.org In-Reply-To: <199607102347.QAA00222@starshine> from "Jim Dennis" at Jul 10, 96 04:47:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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.