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!newshub.tc.umn.edu!lynx.unm.edu!fg1.plk.af.mil!news.zynet.com!imci2!news.internetMCI.com!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: FreeBSD vs. Linux
Date: Wed, 12 Jun 1996 13:53:26 -0700
Organization: Me
Lines: 201
Message-ID: <31BF2E46.2905FF77@lambert.org>
References: <318FA7CB.8D8@hkstar.com> <31B0E3BD.60B31603@lambert.org> <4p2a2u$m99@Mercury.mcs.com> <31B9257C.7246CEC@lambert.org> <4pmpt9$t99@Mars.mcs.com>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Leslie Mikesell wrote:
] >] >SMB servers and NetWare servers *do* have a concept of user;
] >] >they just don't have the concept seperate from connection.
] >]
] >] Some do, some don't (WFWG, Win95 don't know about file ownership).
] >
] >Knowing about only one user is different than knowing about no
] >users.
] >
] >They know about one user: the user that can be authenticated
] >via a network connection with the password/login requirement,
] >or the user who, by default, owns all the files on the system,
] >and is implicitly logged in if the password controls are
] >disabled.
]
] You keep missing my points here:
] (a) An existing workable product is much more useful than a
] non-existing perfect product.
] (b) Just because a product allows you to do something wrong
] doesn't mean you are required to do it that way, or that
] the product shouldn't exist.
You are missing my points here:
(a) Not addressing the security model correctly makes the
product inherently unworkable.
(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.
] >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.
] >] 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.
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.
] >If you do *not* map them on a file-by-file basis, you have
] >subverted the security model on the server. The security
] >model on the server, further, requires that the server
] >administrator be capable of determining enforcement criteria
] >(for instance: logging accesses to a give file by user ID,
] >and other auditing functions). You have not offered the
] >server administrator the right to discontinue service to
] >only one user on your system, if you system of multiple
] >users uses but a single credential.
] >
] >It is, by definition, broken to allow this kind of proxy access.
]
] First, let's start by assuming that the server administrator trusts
] the unix client administrator, or in the usual case is the same
] person. If this isn't the case, he simply doesn't give out the
] password to the shares. Nothing is broken. It is certainly no
] more broken than mapping unix id's into an SMB server's concepts
] since root can impersonate anyone. And not much more broken than
] passing uid/gid numbers in an NFS packet that anyone can forge.
I can trust Bob, "root" user of system "vahl".
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").
You *CAN'T* use vouch-safe authentication when the remote server
won't let you vouch multiple credentials across the same server
connection... which is *EXACTLY* what happens with DOS servers.
] >By creating a credential and providing a client-level login.
] >The UNIX user is the client, not the UNIX machine itself. A
] >client identity is a user identity, as far as the server is
] >concerned. The UNIX server share access model must allow
] >the server to continue enforce its security model. When you
] >have an intersecting set of rights, security dictates that
] >you take the subset, not the superset, of the rights.
]
] 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.
] >I can delete an encrypted file to which I have access without
] >caring what it contains. This is the problem.
]
] If it is your job to make backups of the file, why would you
] delete it?
You wouldn't.
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.
] 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.
I also did the code review on the Novell NUC (NetWare UNIX Client)
product while I was an engineer at Novell, and am well aware of
what the design of a workable model looks like and how it should
act.
I'm telling you that you are causing security holes through the
violation of the principle of least astonishment with your model.
Feel free to implement your own version of the code.
] >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.
] Since we are talking about non-existing products anyway,
Actually, I implemented an SMBFS VFS right after talking Andrew
into rereleasing his SMBServer product (now called "Samba"). I
have first hand experience with the security holes of which I
speak, and of working code (NUC) using a correct model.
] 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")?
What about "secure zone"-based vouchsafe authentication using
reserved ports? Throw out rlogin/rsh/etc. in favor of demanding
a login?
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.