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!howland.reston.ans.net!newsfeed.internetmci.com!in1.uu.net!in-news.erinet.com!ddsw1!news.mcs.net!not-for-mail From: les@MCS.COM (Leslie Mikesell) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: FreeBSD vs. Linux Date: 18 Jun 1996 01:05:39 -0500 Organization: /usr/lib/news/organi[sz]ation Lines: 137 Message-ID: <4q5gvj$7ga@Mercury.mcs.com> References: <318FA7CB.8D8@hkstar.com> <31BF2E46.2905FF77@lambert.org> <4q4f24$424@Mercury.mcs.com> <31C613D8.1188135B@lambert.org> NNTP-Posting-Host: mercury.mcs.com In article <31C613D8.1188135B@lambert.org>, Terry Lambert <terry@lambert.org> wrote: >] I don't disagree here, but the only security model on a unix machine >] is 'root maintains security'. That stuff about uid/gid values is >] just a convention for polite society. > >They are a _bit_ more than that. 8-). They are a credential >that's associated with a process. The issue is the degree of difficulty to forge them as viewed from somewhere else on the network. If it is trivial, why bother with the clumsy illusion? >] >Better to put the mount/credential/connection association into >] >the FS implementation and not put a 16 or so user limit on the >] >number of allowable concurrent users on your UNIX system. >] >] How does this help if the remote resources are all on different >] machines? That is, you have mapped a user's WFW/Win95 machine >] into a Linux mount point, probably under his own home directory >] where he can manipulate it sensibly with cron commands, access >] it from ftp and possibly an http server, and you can back it up. > >You want to mount server exported resources into a common client >per resource mount point. Then you want to be able to send Bob's >accesses to the mount point or inferior nodes over the server >connection established using the "Bob" server credential, so the >server can enforce things like trustee rights, and so on. It >would be convenient (but not a requirement) if you could map >some command to server permission controls to allow user >manipulation of controls (per NFS). Permissions, etc.. The server resources may very well be separate in the first place so there is not necessarily an advantage to agregrating connections. >It's intuitive to Bob that giving out his password is dumb. It's >not intuitive that mounting a remote FS into the UNIX FS hierarchy >won't propagate user access controls. Huh? Not intuititive to whom? How long would it take you to make a CDROM available to a subset of your users? Why would you think any differently about mounting an smb-shared resource? >It's also not intuitive that you could give 16 users access to >the mounted resource, but deny access to a 17th easily, and >without paying through the nose, in terms of committed resources >and mount points and large, evil tables of loopback mounts that >have to be updated every time you add or delete a user, etc.. I'd rather deal with a 16 mount point resource limit than a 0-mount point limit... PC's are cheap, buy more if something is working. And I think people are using linux smbfs with the automounter - at least it is mentioned in the documentation somewhere. >It's unusual because volume mounts aren't usually "things" you >treat like that. Where do you put your CD's with the credit card phone billings? >] Throw out rlogin/rsh and replace them with ssh which >] may or may not use a login depending on the situation. Then >] build the encryption layer into the application itself so the >] files can be secure as well as the network session. >Application encryption is evil; it's unshared code bloat, if >nothing else. Does anyone still use machines that can't run shared library code these days? If the app doesn't do it itself, it has to trust the OS(es), the network, and the filesystem, none of which are generally trustworthy. What we need is a standard library routine and a way to push the decryption out to the closest layer towards the user possible. >The first order of business is to establish a "session manager" >process seperate from an authenticated UNIX process to operate >as a "credential holder" for all processes owned by that user; >it will need to handle "session instances", one per authentication >by the user to the UNIX system. Probably, we will need to have >a session management system call with "add session" and an implied >"delete session" in _exit and an implied "add session" in the >kernel fork code. > >After that, we need to have a way to register a responder process >to communicate with the session manager, and we need to have a >way for the kernel to communicate with responders. I think ssh already gets this right. >Then we need to build repsonders into each of the existing >session managers -- xdm, screen, etc. -- and we need to build >in a "popup" facility for the console to hook the default >session manager. >Then the kernel can ask the user to authenticate for a resource, >be it a password protected directory, or whatever. If there isn't >a registered responder, access is denied. But this poses an impossible problem. The reason I want to mount smb-shared resources into unix hosts is almost never to make them available to an interactive user at a predictable place. These resources mostly live on a user's desktop and I want to do something to them automatically under program control using unix's handy job scheduling facilities or perhaps access them remotely through the unix network functions lacking on the desktop PCs. My multi-user servers are already unix boxes sharing their files via smb services and the clients already map into unix users. I don't have the conceptual problem you are imagining where you might try to map an unrelated NT server's user into mismatching unix id's. I just want to avoid storing everything on the server just to gain the advantage of having access to the files from unix programs. Before windows, it wasn't too bad to do this, but I really don't want to load windows apps across the network. >The hardest part will be login/telnetd/rlogind/rshd/xterm/screen/etc. >changes, IMO. Ssh already does rsh/rlogin/rcp and X sessions and encrypts/compresses the network activity. (Unfortunately it seems to crash one of my BSDI machines unpredictably but that's probably a hardware problem.) However, I don't see how you can make this extend to SMB servers where you don't have source. Does the new network filesystem spec recently announced by Microsoft and a few other players address this? >I'm game, if you are; though I can't commit a lot of time to >the project, I certainly can commit some. I'm not sure I see any benefit to this until you can do encrypted sessons with the smb server and do the session setup with a public/private key exchange like ssh. It might be possible to do something interesting using an ssh session to tunnel traffic between two trusted machines on an otherwise untrusted network if you could make the endpoints act like routers. Les Mikesell les@mcs.com