pst@comdesign.cdi.com (Paul Traina) (11/17/88)
To reiterate past concerns briefly:
I'd like bin to own system executables, but I'm worried about
the fact that /bin is covered by /etc/hosts.equiv, so if a user
su'ed to bin on one machine, he could rlogin/rsh to another machine
and change anything owned by bin. The same sort of thing can
happen with remote-mounting the disk.
One solution was to have root own everything. This has drawbacks
which I won't reiterate.
Potential solution:
How about if we add a new 'first-character' to the password file
on a system. Currently we have '*' which sort-of signifies that
the userid is not loginable (has no password).
Could we add something like a '%' to the beginning of a password
field, which would then imply that /etc/hosts.equiv should not
be checked for rlogin/rsh (but of course ~/.rhosts could be), and/or,
if a filesystem is remotely mounted, any remote user-access comes
in as 'nobody' (just like root).
This way, we could protect accounts by adding a '%' to the start of the
password field. If this was used on certain sensitive "user" accounts too,
some mods to /bin/passwd and /bin/login would have to be made too, so that
pst:AZKjhjk38h$:332:51:Joe Luser:...
would become:
pst:%AZKjhjk38h$:... (and passwd & login would ignore the first char)
Comments? What are the drawbacks (other than in a NFS universe, where this
would be troublesome for "real" users as opposed to pseudo-users like bin and
sys)? This would seem to extend some of the protections provided to root to
any arbitrary user.
------
Paul Traina To believe that what is true for
{uunet|pyramid}!comdesign!pst you in your private heart is true
pst@cdi.com for all men, that is genius.haynes@ucscc.UCSC.EDU (99700000) (11/17/88)
But, but, but... entries in hosts.equiv mean that the machines
are under the same administration, hence all names are protected
across all machines. If you have a machine on which someone can
masquerade as bin then that someone can masquerade as anybody else,
so you've got lots worse problems than merely bin.
haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes
"Any clod can have the facts, but having opinions is an Art."
Charles McCabe, San Francisco Chroniclenews@rosevax.Rosemount.COM (News administrator) (11/18/88)
In article <566@comdesign.CDI.COM> pst@comdesign.cdi.com (Paul Traina) writes: > I'd like bin to own system executables, but I'm worried about > the fact that /bin is covered by /etc/hosts.equiv, so if a user > su'ed to bin on one machine, he could rlogin/rsh to another machine > and change anything owned by bin. I haven't tried this, but the manual says that the user's .rhosts file is read BEFORE rhosts.equiv. So you should be able to put a .rhosts in bin's home directory, and configure it to deny rlogin/rsh to all hosts. This should override the general permissions in hosts.equiv. Dan Messinger dan@ernie.rosemount.com
pst@canary.cdi.com (Paul Traina) (11/20/88)
From article <6710@rosevax.Rosemount.COM>, by news@rosevax.Rosemount.COM (News administrator):
< I haven't tried this, but the manual says that the user's .rhosts file is
< read BEFORE rhosts.equiv. So you should be able to put a .rhosts in
< bin's home directory, and configure it to deny rlogin/rsh to all hosts.
< This should override the general permissions in hosts.equiv.
<
< Dan Messinger
< dan@ernie.rosemount.com
Yet another good idea, but none of these address the 'root/bin' as NFS
problem. I'm sure that there's something that I've overlooked. Perhaps
puting stringent netgroup requirements on the system, and not allowing
root/bin/adm write access to certain partitions? Currently I am unaware
of any ability within UNIX & NFS to provide such a selective level of
security.
p.s. moved followups to comp.unix.wizards, since this really isn't a bug.
------
Paul Traina To believe that what is true for
{uunet|pyramid}!comdesign!pst you in your private heart is true
pst@cdi.com for all men, that is genius.woerz@iaoobelix.UUCP (Dieter Woerz) (11/28/88)
In article <566@comdesign.CDI.COM> pst@comdesign.cdi.com (Paul Traina) writes: > ... >Potential solution: > > How about if we add a new 'first-character' to the password file > on a system. Currently we have '*' which sort-of signifies that > the userid is not loginable (has no password). > > Could we add something like a '%' to the beginning of a password > field, which would then imply that /etc/hosts.equiv should not > be checked for rlogin/rsh (but of course ~/.rhosts could be), and/or, > if a filesystem is remotely mounted, any remote user-access comes > in as 'nobody' (just like root). I would prefer to do it like (I think) RSX or VMS, which has a configurable Parameter, which UIDs are to be treated as system. If I remember correctly, RSX had the uids 1 to 10 be the equivalent to system, that is if you had one of these uids, you had the same privileges as the system account. This would allow the system files to be owned by bin, but allow the SA have bin to be protected by like the root account or (if he wants to) like the account of a normal user. ------------------------------------------------------------------------------ Dieter Woerz Fraunhofer Institut fuer Arbeitswirtschaft und Organisation Abt. 453 Holzgartenstrasse 17 D-7000 Stuttgart 1 W-Germany BITNET: iaoobel.uucp!woerz@unido.bitnet UUCP: ...{uunet!unido, pyramid}!iaoobel!woerz