Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!inquo!in-news.erinet.com!bug.rahul.net!rahul.net!a2i!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: 12 Jun 1996 11:06:01 -0500
Organization: /usr/lib/news/organi[sz]ation
Lines: 145
Message-ID: <4pmpt9$t99@Mars.mcs.com>
References: <318FA7CB.8D8@hkstar.com> <31B0E3BD.60B31603@lambert.org> <4p2a2u$m99@Mercury.mcs.com> <31B9257C.7246CEC@lambert.org>
NNTP-Posting-Host: mars.mcs.com
In article <31B9257C.7246CEC@lambert.org>,
Terry Lambert <terry@lambert.org> 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.
>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).
>] 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.
>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.
>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.
>] >This is a harder problem to solve. People seem to be willing
>] >to sacrifice security rather than addressing this issue; in
>] >particular, the Linux SMBFS does exactly that: sacrifices
>]
>]
>] Or, perhaps if they have no particular need for additional
>] security (i.e. everyone on the net would be members of the
>] group with access anyway). Or perhaps they use applications
>] which provide their own security mechanisms, like MS access with
>] encrypted data files. In my opinion this is the correct
>] approach since it requires no particular trust in either
>] the network or operating system. (Although I don't know how
>] well access does it...).
>
>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?
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've always been able to set up a
workable system where each user had one 'private' area on the
server, one read-only connection to a directory containing programs
and other site-wide resources, and building-wide and per-department
read/write areas to share files. Exchanges that don't fit this
model can be done by email or ad-hoc means. The point here is
simply that mapping permissions to the share level and providing
as many shared areas as you need makes it trivial to map this
back into mount points on a unix client, with appropriate
permissions controlling access to the mount point.
>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. Since we are talking about non-existing products anyway,
I think the effort should go into making the application layers
secure regardless of the transports, and simply make the transports
handy.
>In any case, of those which do, and which operate on servers
>of this type, how many run on UNIX?
It is not necessary for any particular machine to run the application
in question to make it useful for it to be able to access the file.
For example you may want to do backups from a single network point,
or you might want to make an encrypted file available via ftp or http
from a machine that doesn't run those protocols or where you don't
want to maintain their access control setups separately.
There are many other situations that don't map into the usual concept
of users. One I'm currently using is a data collection program that
is only available for DOS, but since I want access to the files from
unix I save it to an SMB-shared directory on a unix host. However
this causes problems when the network or server is down. I'd much
rather reverse the situation and mount the PC's drive into the
unix host.
Les Mikesell
les@mcs.com