Date: Sun, 8 Dec 1996 14:19:49 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jfieber@indiana.edu (John Fieber) Cc: msmith@atrad.adelaide.edu.au, wangel@wgrobez1.remote.louisville.edu, freebsd-current@freebsd.org Subject: Re: samba Message-ID: <199612082119.OAA29467@phaeton.artisoft.com> In-Reply-To: <Pine.BSI.3.95.961208102256.7950J-100000@fallout.campusview.indiana.edu> from "John Fieber" at Dec 8, 96 10:31:23 am
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sun, 8 Dec 1996, Michael Smith wrote: > > > Please go back and read the mailing list archives for the meat of the > > last N times this has come up. Searching for 'smbfs' is probably a > > good place to start. Look particularly for Terry's detailed rants on > > the topic. > > To quote from the motd on freefall: > > sd3 passed away at 7:05AM PST. RIP. A replacement drive will be > ordered ASAP. Lots of stuff has died with it, expect chaos for a > while. > > The mailing list archives are among the dead. :( > I just hope some backups exist. Well, I keep everything I post, and everything everyone says in response to one of my posts, and most discussions I find interesting, and most discussions which reveal non-obvious hardware information. So while I don't keep the majority of list traffic, I do keep some, even if I have to edit it down for content occasionally. Here are the most relevent saved pieces from the last SMBFS discussion: ========================================================================= FROM THE MOST COGENT CREDENTIAL MODEL DISCUSSION ========================================================================= | Sorry, but I can't accept "no user level security" as "good enough", | when the SMB model depends on connection credentials to impose the | will of the SMB server administrator. | | What we are arguing here is whether it is acceptable under any | circumstances to subvert the ability of the SMB administrator to | impose his will on his system. | | My answer for that is "no, it's not -- it is his box, and he is God, | what he says must go". | | You can't really balance this with the UNIX model -- that's the | whole point, that the models are not directly interoperable. | | | There are ways around this problem, and in the last set of "go-rounds" | in usenet, I even offered to work on a general soloution -- though not | solely on my own -- to the credential problem. It turns out my | correspondant was more up for arguing about why I should release | crap code instead of wanting to work on good code. I let the thread | die on that note. ========================================================================= THE USENET POSTING REFERENCED ABOVE ========================================================================= | 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 (like 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. ========================================================================= DETAILED INFORMATION ON THE CREDENTIAL MAPPING PROBLEM ========================================================================= | > Download ksmbfs from: | > ftp://samba.anu.edu.au/pub/samba/contributed/ksmbfs-0.2.4.tgz | | How do you resolve: | | 1) It's GPL'ed code | | 2) It does not allow per-user enforcement of credential mapping | | The first is not really a kicker if it's distributed as an LKM, and the | LKM is not distributed pre-loaded. Its just that you can't sell or | even give away the agregate system because of the license conflicts. | | | The second is a serious issue, since it damages the SMB server | administrators management authority to have all users from a given | UNIX box appear as as a single SMB client. This was my objection | to the SMBFS suggestions I have seen in the past. | | I did an SMBFS for FreeBSD 1.1.5.1 (so it would be a hard port, and | it is code Novell/USG claimed they owned because I was a Novell | employee when I did it on my own time before Novell bought USL). | | The credential problem is significant, and I did not solve it in | my prototype code. | | | IF FreeBSD supported attaching additional credential information to | a session (ie: it had the concept of a session manager, which it | applied to normal console logins, as well as to "screen" and "xdm" | logins), then it would be possible to implement a method of querying | the user asynchronously for the information the kernel needs to | establish a seperate connection credential for the user for a given | mount. | | For remote sessions, and for TTY's, where it is impossible to pop | up a "dialog" without potentially destroying unrecoverable screen | contents, preauthentication would be required. This basically means | adding an EAUTH error code to all pathing operations, and handling | the error return in all programs which invoke those system/library | calls. Then the applications can self-handle querying for authentication | without damaging the application context. There is also the posibility | of a Window95-style "password cache" in this scenario, the cache being | managed by the session manager, and cache unlocking forced at login time | along with standard system login. This incidently buys you the ability | to have password protected directories and files, since the missing | piece for that FS extention is the ability to query the user for | authentication data; same problem, different context. | | | But short of this, porting SMBFS directly is a bad idea, since it damages | existing security models on servers we can't do anything about because | they come from Microsoft, or AT&T, or IBM, etc., and they don't have | source code. There is no way to repair the damage, other than to note | it, and have the SMB server administrator react appropriately (which | is undefined, since the situation never arises without SMBFS rearing | its ugly head). | | If you intentionally go ahead and damage someone else's security model | by making an N:1 mapping of a resource which is, by design, expected | to be 1:1 mapped by a single user client machine, be prepared to take | a lot of heat for doing it. | | This is *exactly* the problem the NUC (NetWare UNIX Client) people at | Novell dealt with in UnixWare, NeXTStep, etc., and exactly the issue | that caused them the most grief in their 20 man year (5 engineers over | 4 years) project to solve the problem uniformly and securely. | | | My offer to help work on a session management interface (made in a | Usenet posting on SMBFS) still stands; there did not seem to be a lot | of interest in resolving the general problem, when a kludge soloution | was so close. 8-(. > > The linux smbfs is, in the tradition of Linux, a festering hack, and > > this isn't exclusively the fault of the implementors. > > Alas, if you rate software on two scales: elegantly engineered > solution to festering hack, and useless to useful, I'd hazzard a > guess that if there is any correlation, it would be positive > (associate the festering hacks with higher utility). I'd have to say that you have neglected the case where utility was a design criteria. 8-). > Non-programmers don't care *how* the programmer implements > something, so long as it works most of the time. Evidence? > Microsoft products. I rest my case. "How are you going to keep them down on the farm after they have seen Paris?" This is a case of them not having high expectations because they have never seen something which would meet high expectations. Once they have seen something like that, their expectations will have been raised. Do you think Microsoft Engineers really *wanted* to work on protected memory interfaces instead of the next API for video games? Do you think they *wanted* to give away networking or Internet Explorer instead of charging for it? They are backing down skirmish lines to retrench... not acting out of choice. CIFS (SMBFS) is to WebNFS as ActiveX Components are to JAVA Applets. 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?199612082119.OAA29467>