*BSD News Article 71251


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