Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!news.kei.com!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: Mon, 17 Jun 1996 19:26:32 -0700
Organization: Me
Lines: 249
Message-ID: <31C613D8.1188135B@lambert.org>
References: <318FA7CB.8D8@hkstar.com> <31B9257C.7246CEC@lambert.org> <4pmpt9$t99@Mars.mcs.com> <31BF2E46.2905FF77@lambert.org> <4q4f24$424@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:
] 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.
They are a _bit_ more than that. 8-). They are a credential
that's associated with a process.
] >(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.
You can layer exclusion groups and other ("sudo") protections on
top of the model. The difference is between concsious and
unconscious compromise of the model.
] >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.
He can't pretend to be "root" instead of "nobody".
He can vouch all my unpriviledged users and/or groups, if I
let him. It's a zone based approach to security, with firewalls
to wall in zones.
I don't have to trust him completely, only with my unpriviledged
users (or completely, or not at all).
I can also set up "netgroups" to differentiate "foreign" zones.
] >] >] 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?
I suspect that you aren't considering the case where "Bob the DOS
user" and "Bob the UNIX user" want to get at the same files.
] >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.
You want to mount server exported resources into a common client
per resource mount point. Then you want to be able to send Bob's
accesses to the mount point or inferior nodes over the server
connection established using the "Bob" server credential, so the
server can enforce things like trustee rights, and so on. It
would be convenient (but not a requirement) if you could map
some command to server permission controls to allow user
manipulation of controls (per NFS). Permissions, etc..
Probably trustees are out of the question, without an FS specific
fcntl() and a user tool to call it.
] >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.
It's intuitive to Bob that giving out his password is dumb. It's
not intuitive that mounting a remote FS into the UNIX FS hierarchy
won't propagate user access controls.
It's also not intuitive that you could give 16 users access to
the mounted resource, but deny access to a 17th easily, and
without paying through the nose, in terms of committed resources
and mount points and large, evil tables of loopback mounts that
have to be updated every time you add or delete a user, etc..
[ ... ]
] >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.
Except everything that *is* intuitive. 8-).
] And what is abnormal about putting things you want to secure
] down a path with the customary permission settings used to
] control access?
It's unusual because volume mounts aren't usually "things" you
treat like that.
] >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.
Making "/etc/group" the file where the "evil tables" are stored.
8-).
] 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.
Generally, user areas of DOS file servers are on a single volume
and differentiated by the user credentials. On NetWare, this
means I can only see my directory on the volume because of default
trustee right inheritance settings for the directory the user
directory is in, and my ownership (by credential) of my directory.
] >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.
Might as well ask for an "intuitive UNIX". ;-).
] >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?
That he's not commiting a crime with a penalty not to exceed 20
years in a Federal Penitentiary. 8-).
] 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.
Application encryption is evil; it's unshared code bloat, if
nothing else.
I'd like to work on a credential passing mechanism... I have
a full understanding of the Windows95 password cache, and a
more-than passing knowledge of BSD. 8-). If you wanted to
deal with the credential issue so we can avoid the security
holes, I'd be more than willing to help where I can.
The first order of business is to establish a "session manager"
process seperate from an authenticated UNIX process to operate
as a "credential holder" for all processes owned by that user;
it will need to handle "session instances", one per authentication
by the user to the UNIX system. Probably, we will need to have
a session management system call with "add session" and an implied
"delete session" in _exit and an implied "add session" in the
kernel fork code.
After that, we need to have a way to register a responder process
to communicate with the session manager, and we need to have a
way for the kernel to cummunicate with responders.
Then we need to build repsonders into each of the existing
session managers -- xdm, screen, etc. -- and we need to build
in a "popup" facility for the console to hook the default
session manager.
Then the kernel can ask the user to authenticate for a resource,
be it a password protected directory, or whatever. If there isn't
a registered responder, access is denied.
For Network login, an "autoresponder", maybe with a password
cache, maybe without, can have "net login" per validated
keys for use in responding to requests. If there isn't a pre-key,
accessis denied.
Then for a weenie shell, I can put stuff in my .login, and for
X or screen (and maybe the console) I can pop up a resource
specific login requester (if needed -- maybe it will be there
in the cache already).
The hardest part will be login/telnetd/rlogind/rshd/xterm/screen/etc.
changes, IMO.
I'm game, if you are; though I can't commit a lot of time to
the project, I certainly can commit some.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.