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!in2.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: FreeBSD vs. Linux
Date: Sat, 08 Jun 1996 00:02:20 -0700
Organization: Me
Lines: 138
Message-ID: <31B9257C.7246CEC@lambert.org>
References: <318FA7CB.8D8@hkstar.com> <4o584s$n9l@uriah.heep.sax.de> <4ogkn2$20b@Mercury.mcs.com> <31B0E3BD.60B31603@lambert.org> <4p2a2u$m99@Mercury.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.
This is very different than not having a credential associated
with the client connection at all.
] >This is an implementation issue for an SMBFS, and is trivial to
] >address.
] [...]
] >This is because UNIX credentials are associated with sessions,
] >and a session ID is synonymous with a process group leader,
] >and the credentials are associated with the proc struct instead
] >of being use in common for all processes with a given user ID.
]
] None of which makes any sense to the sorts of things you are
] likely to want to do to a remote machine, like deliver mail
] proxying for many users, or full backups.
Mail proxying requires crednetial proxying. If you do not
credential proxy, you "root" proxy. NT handles this internally
by using "impersonation" threads which associate an ACL with the
thread ID.
] >NFS uses this credential model by having the client user on
] >a given host have to run on a "trusted" host to allow the
] >kernel to proxy the user credentials to the server by inserting
] >them into the packets that go acress the wire.
]
] Which means, of course, that root on the client machine can
] pretend to be anyone on the shared area of the server.
Yes. The client machine must be "trusted". This is called a
"vouchsafe" system. It is similar to the security used by the
rcmd/ruserok calls for the rsh/rcp/rlogin/rmt protocols, which
use a priviledged source port to identify the source user as the
root user.
In contrast, the model used by all SMB and NetWare servers (even
those which only understand a single credential) associate the
credential to the connection, or (in NDS), with a key token.
This is similar to the system used by kerberos authentication
in UNIX systems. The difficulty in using the key token (or
ticket) for other-than-kerberos authentications is that the
ticket is generated in a context, which is not requestable
by the kernel. That is, the ticket instance for an SMB or
NetWare ticket is not possible to generate as a result of a
user interrogation by the kernel.
] >Because SMB and NetWare servers don't have the concept of
] >"trusted host", a proxy approach won't work. The conversion
] >of credentials must take place on the client system.
]
] 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?
Because the credentials are expected to be enforced on the
server, they are not exported to the UNIX system for mapping
via the wire protocol: they do not exist but for the server.
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.
] >This is easier to think of if you think of each login session
] >on a UNIX box as an authentication instance (or "client").
]
] Only if you want the security to map to unix models. In fact
] it tends to be difficult to set up the network model that is
] needed for most office work under unix - that is, a number
] of groups who need read access to one set of files, read/write
] to another set, where some individuals are members of many
] groups and others should be restricted to their own. Some
] versions of unix will let you be in multiple groups at once,
] but how are you going to map this into the SMB model?
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.
] >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
] >user-level security for a marginal improvement in convenience.
]
] 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.
Most applciations do not layer security on top of that provided
by the network itself. Those which do are generally redunant.
In any case, of those which do, and which operate on servers
of this type, how many run on UNIX?
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.