Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!root%bostonu.csnet@csnet-relay.arpa
From: root%bostonu.csnet@csnet-relay.arpa (BostonU SysMgr)
Newsgroups: net.unix-wizards
Subject: Another reason why a few sources should come with binary licenses
Message-ID: <1149@brl-tgr.ARPA>
Date: Sun, 1-Sep-85 09:30:05 EDT
Article-I.D.: brl-tgr.1149
Posted: Sun Sep  1 09:30:05 1985
Date-Received: Mon, 2-Sep-85 09:05:37 EDT
Sender: news@brl-tgr.ARPA
Lines: 57


Is this an unreasonable (or useless) place to air this? My hope is
some reasonable (most) people from ATTIS read this list. If not
send me a few flames and I'll shut up.

The argument thus far is that binary licenses to UNIX should always
come with a few sources because of various security and administrative
policies that a site might need to institute that shouldn't require
a full source license, among those mentioned were login.c. So far the
list has been:

	1. The ULIMIT problem, modifying login.c is currently the
	only effective way to raise ulimit above 2048 on SYSV.

	2. Enforcing times when certain users can or cannot login,
	or other variables (eg. load, free dialups available etc.)
	This *could* be done via /etc/profile but I think most would
	agree it belongs in login.

	3. Schemes like if they type in N bad passwds hang the phone up,
	maybe warn someone (the user or SA.)

Here's another one that was just brought up on the SECURITY mailing list.
If user's are not careful about password creation (and people are just
people) then a reasonably determined cracker can grab the encrypted string
in /etc/passwd and run it against dictionaries (this is all well documented
in "The Security of UNIX", I think that was Kernighan, sorry, working from
memory here.)

A trivial defense (used I believe years ago at Harvard and probably lots
of other source sites) was to make /etc/passwd a dummy file (so most
software is undisturbed) which does not contain encrypted strings but
otherwise is publicly readable. You then create another, unreadable,
copy (call it /etc/passwd.nr) with the strings. The only two programs
that I can think of that use those encrypted strings (as delivered) are
login.c and passwd.c, just modify those to use the unreadable version (easy.)
It would also be handy to have a script that can be run that builds the
readable from the unreadable when it is modified (easy.) 

If need be, passwd.c could be re-written by any competent applications
programmer in an afternoon. Login.c is quite subtle and would be a bit
of a job to rewrite from scratch without having access to its source.

So, another sound argument I believe that certain software sources should
always be delivered with UNIX systems (hey, we're a University, we get
sources to all of this stuff, but my binary only PC7300 got me thinking.)

Now, another security/integrity problem on UNIX I would like to hear
a discussion on: /tmp. Let's face it, it's a problem (anyone can do
an 'rm /tmp/*', or fill it with junk, or usually read many files on
it.) How about considering a temporary file type (maybe by making /tmp
a device?) with some special rules (delete on last close, no name in
the visible file space except to root etc.) Of course any design should
be ignorable (transparently work the old way at sites that don't need it,
like my UNIX/PC.)

	-Barry Shein, Boston University