Security

[MCLI...@rutgers.arpa]

From: Sean McLinden <MCLI...@RUTGERS.ARPA>

Not meaning to beat a dead horse, I think that it would be worthwhile
to distinguish between those playful users who are "friendly" but
mischievous and those who (if given the opportunity), would do harm
to a system. In the first category might be included co-workers and
system programmers (hackers). In an office setting, it
may be nearly impossible to keep passwords a secret and anyone who has
access to the machine console could easily bring the system down and
back up in a single user mode, security notwithstanding. Having been
both a system administrator and a programmer it seems to me that
securing a system from the playful but trusted user is more a matter
of education and less one of heavily guarding machine and system
secrets (which is all but impossible anyway).

The non-trusted user is a different story. Amost anyone with the
desire can learn the inner workings of UNIX. Unlike IBM and
(to a certain extent, DEC operating systems), practically
eveyone who has UNIX license (educationally), has a source license
and the sources are easy to get a hold of. The idea of creating
restricted shells has been mentioned before and is frought with
possibilities. For example, consider the following (very
trivial), example:

/* newroot.c */

main()
{

chroot ("/usr/guest");
execlp ("csh" , "csh" , "-f " , 0 , 0);
}

This program, run setuid root, will create a shell (csh), whose
idea of "root" is /usr/guest. Done properly,
chroot (which exists in 4.1 but which isn't documented), could
be used to create systems with their own "super user",
their own password files, and assuming that these separate
roots can run init(), a system could be created
completely secure from other systems on the same machine. The
drawback is, of course, that certain files and utilities would
have to be duplicated for each system. On the other hand this
may be one mechanism for isolating potential trouble spots
from the entire system.

Sean McLinden
-------

[p...@ukc.uucp]

If people are REALLY WORRIED about the decryption of passwords
why not move the passwords to another file, which is read-only
by root. After all only passwd and login need to access the file
and both of them are setuid.

At UKC, we have user populations of 600-700 and have totally
replaced the password file by a binary file with some integral
number of bytes per user. This means that random access can be used
to access an individual entry. Other keys to the password file (such
as login name and in our case the user's system id) are abstracted
to a set of very small files which are kept in uid
order - these files can be opened and searched very easily.

For compatibility purposes we generate /etc/passwd every night (with
no passwords) and passwords are never printed even in their encrypted
form.

One of the benefits of a binary password file is that the record for
each user can be much bigger. We currently store a set of limits
which are applied at login time and we plan to put in the set of
groups which can be used for 4.1c/4.2.

Peter Collinson

{mcvax, vax135} !ukc!pc

[t...@unc.uucp]

It is not true that only login and passwd need to read
/etc/passwd. The GCOS field is used for maintenance of a user
information database on many systems, requiring that the file be
readable by finger as well. Of course, finger could be made setuid to
root, or a different file could be used for the database.

______________________________________
The overworked keyboard of Tim Maroney

duke!unc!tim (USENET)
tim.unc@udel-relay (ARPA)
The University of North Carolina at Chapel Hill

[g...@rlgvax.uucp]

1) Anybody out there know *why* the 4.1BSD manuals don't document "chroot"?
The V7 manual does, and the System III and System V manuals do.

2) On a vanilla V7 system "chroot" is *not* secure. You can reference above
your fake root with "..". This bug has been fixed in 4.1BSD and in System III
and later USG releases. In fact, there is an undocumented feature of the
System III "login"; if the user's login shell begins with "*" (or is "*"),
"login" changes the root to the home directory specified in the password file,
prints "Subsystem root: <that_directory>", and attempts to run "/etc/login"
and, if that fails, "/bin/login" from the new root. The System V login does
all this (which implies it wasn't just a hack) and also sticks the string
<!sublogin> in the environment (that's right, a string in the environment with
no "=" in it!). My interpretation of this is that you put an entry for the
*subsystem*, not for the *user*, in the password file (i.e., if you had a
subsystem called "anonymous", you would have:

anonymous:<encrypted subsystem password>:<uid>:<gid>:<name>:/anonymous:*

in the password file. Then you would put the password file for the anonymous
user subsystem in "/anonymous/etc/passwd", and either a copy of/link to
"/etc/login" or a special login program in "/anonymous/etc/login". Is this
how it is intended to be used? And why is it not documented in the System III
or System V documentation?

Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy

[bob%ucl...@sri-unix.uucp]

From: Bob English <bob@ucla-locus>

I believe the proposal was to remove the password from
/etc/passwd and place it in a separate, non-readable file.

--bob--

[re...@umcp-cs.uucp]

As far as 4.x bsd and chroot(), there is no danger. namei() checks
whether you are in your root dir and throws away ".."s if you are.

-Rehmi
--
By the fork, spoon, and exec of The Great Basfour.

Arpa: rehmi.umcp-cs@udel-relay
Uucp:...{allegra,seismo}!umcp-cs!rehmi