Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!howland.reston.ans.net!world1.bawave.com!news2.cais.net!news.cais.net!van-bc!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: 17 Jun 1996 15:26:44 -0500 Organization: MCSNet Services Lines: 170 Message-ID: <4q4f24$424@Mercury.mcs.com> References: <318FA7CB.8D8@hkstar.com> <31B9257C.7246CEC@lambert.org> <4pmpt9$t99@Mars.mcs.com> <31BF2E46.2905FF77@lambert.org> NNTP-Posting-Host: mercury.mcs.com In article <31BF2E46.2905FF77@lambert.org>, Terry Lambert <terry@lambert.org> wrote: >You are missing my points here: > >(a) Not addressing the security model correctly makes the > product inherently unworkable. 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. >(b) The product does not "allow you to do something wrong"; > it "doesn't allow you to do something right". The > difference is critical: there is *no* "right way" to > use a broken (by design) product. And under unix letting root do anything he wants is the "right way" or you might as well throw the whole system out. >] >This is very different than not having a credential associated >] >with the client connection at all. >] >] Not when you take into account that the root user on the client >] machine must make the connection and that you trust him (remember >] that he can also subvert a user-based scheme if he wants). > >You *don't* trust him, unless he is also your network server >supervisor. *THAT'S* the *problem*. >You *ONLY* trust him so far as he authenticates someone as >himself; you *DON'T* trust him to authenticate other people >as himself (which is what he would do, if he didn't provide >you, the server, with per-user credentials. You have to trust him completely or not at all. I agree this isn't ideal, but it is the normal unix model. Would you allow any access to your nfs server from a machine where you don't trust root? Yes, the protocol provides for passing values, but root on the client can pretend to be anyone, or allow anyone else to. >] >] Which means, in the case of unix as a client, that root is >] >] equally responsible for maintaining appropriate access levels, >] >] perhaps by protecting the mount points with the usual methods. >] > >] >How do you apply this on a file-by-file basis against files >] >from the server? >] >] Put them in directories that are shared separately. > >And therefore mounted seperately, each with a different >credential? The mount point traversal lookup code is linear >search, if you haven't looked. I'm missing something here. The remote shares that would be limited to certain users are likely to be on their own machines and thus a separate share/mount anyway, like it or not. But what does this have to do with anything? >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. >But do I trust everyone Bob trusts? > >You are confusing vouch-safe (where Bob says "Fred here is the >same as your Fred") with token sharing (where "IF I trust Bob, >THEN I trust Fred because Bob trusts Fred"). No, you only have to trust Bob not to mount your resource anywhere where people you don't trust can access it. This is approximately the same level of trust as expecting him not to give out the password to anyone you don't trust. >] No, on a unix machine it is up to root to set up and maintain >] security appropriately. If you don't believe this to be the >] case you should not allow that machine any access to files >] with security requirements. If you do believe it (as you probably >] would if the same person is adminstering both machines...), then >] you should trust root to only make the mount points accessable >] to appropriate users. Security is only broken if root mounts >] a share and makes the mount point accessable to inappropriate >] users. > >Yes to "if it were the same person administering both machines". >No to "trust root to only make the mount points accessable to >appropriate users". > >The second is not intuitive, nor is it the way UNIX mounts are >normally organized or implemented. Heh, take away everything that is non-intuitive on unix and you won't have much left. And what is abnormal about putting things you want to secure down a path with the customary permission settings used to control access? >We are not talking about the case where only authorized users >have access, we are talking about what you propose: everyone >who can get at the mount point has equal access, and if the >mount is implemented the way the 'mount' man page says mounts >should be implemented, then that's everyone. Not the mount point itself, the path to the mount point. >] I've used SMB-based networking for many years - all the way back >] to AT&T's first imitation of the IBM PC-NET program where the >] server really didn't have any concept of users, just password >] based access to shares and that provides all the security a >] typical office needs. NT's relatively new concept of users is >] nice but not essential. > >I used StarLAN, too. And OpenNet. And SCONet (the LANMan 1.0 >for Xenix). > >And StarLAN and all other LANMan 2.0 protocol based servers >supported user authentication of connections. My point is that I never found it necessary to put files with different access control requirements into the same directory or share. Isn't that why directories were invented and the servers let you share them separately? In fact I find it easier to provide the 'usual' case of a group of people wanting r/w access to a common area this way than the more convoluted group concepts of unix. >] >Most applciations do not layer security on top of that provided >] >by the network itself. Those which do are generally redunant. >] >] They are not redundant if your network spans untrusted wires >] or hosts, something that everyone needs to do these days or >] if someone untrusted has physical access to your PC's or backup >] tapes. > >This is why we have the concept of "host authentication"... which >you are discarding for SMB hosts with your mount model. If everyone is polite, such conventions might work. >] I think the effort should go into making the application layers >] secure regardless of the transports, and simply make the transports >] handy. > >So you are arguing against firewalls (whose sole purpose is to >make transports "unhandy")? Of course. Nobody likes firewalls. First you spend a bundle to connect to the internet, then even more to keep yourself from being able to do anything important over the connection. And firewalls do nothing to deal with the modems on everyone's desktop which are an equal-opportunity access point, or the backup tape copies. What people want is a secure way to provide access, not wholesale blockage. >What about "secure zone"-based vouchsafe authentication using >reserved ports? Throw out rlogin/rsh/etc. in favor of demanding >a login? What does a 'reserved port' mean to someone who isn't politely following your conventions? 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. Les Mikesell les@mcs.com