Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.sysv386
Subject: Re: Bad login user id(sco-unix)
Message-ID: <18651@rpp386.cactus.org>
Date: 27 Oct 90 12:20:43 GMT
References: <18633@rpp386.cactus.org> <1646@mitisft.Convergent.COM> <1990Oct26.092606.7374@robobar.co.uk>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 63
X-Clever-Slogan: Recycle or Die.

In article <1990Oct26.092606.7374@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes:
>Wrong.  Eamon McManus posted a version of su(1) that *did* change the
>luid -- by scribbling in /dev/kmem.  It should be possible to merge
>Eamon's code into John's login too.

please - don't do gross things to my source code!  i would suggest
that you create a common function to handle dorking with the luid
in kernel memory and just put in a call to it.  the code is being
pounded on by an increasing number of people, and doing lots of
incompatible things will only make for lots of incompatible versions.

>> It is used by the audit trail to allow tracking of 
>> changes in identity.
>
>Do you know anyone who has enough disc space to enable auditing ? (1/2 :-)

sure, i do ;-).  you have heard of tape drives, correct?  create a
daemon process to slurp your audit trail off to tape.  change tapes
on a daily basis.  it should be possible to select the subset of
interesting event.  someone should post the gory details if it isn't.

>> login(1) was extensively 
>> modified to accomodate the requirements of C2.
>
>Those of us interested in John F Haugh III's login suite are attempting
>to subvert the C2 intentions of SCO Unix.  The idea is that there
>should be a "kit" to disable as many of the security features as possible
>to be installed *after* the OS has already been installed -- someone said
>that it must come up in C2 in the beginning, so such a kit would have
>to be installed afterwards.  Such a kit should also be shipped by SCO,
>but until they do so, we do what we can with source provided by kind
>netters :-)

[ it's jfh II - not jfh III.  this has got to be the world's most
  common mistake involving my name.  it was the uncle (dr. j.f. haugh)
  not the father (e.l. haugh), hence ii not jr. ]

i find it difficult to believe that secureware went that crazy with
this notion of login id's.  there is no C2 requirement for this
bizarre of a user i&a scheme.  in fact - there is no tcsec requirement
for unchangable id's at any level.  the only real requirement is that
if you are going to change your id the event must be auditable and
you must be authenticated (section 2.2.2 tcsec).  sigh.  why must
implementors constantly strive so hard to make security unusable?

as for making a kit to get around the secureware changes, paul vixie
posted a really nice cron some time back, and bill wells posted a
getty; you get login, su, newgrp (e-i-e-i-o) with my shadow password
suite, and i've even seen a ct that i forget who posted.  the only
changes should be programs which dink with uid's and create new
login sessions.

given what i have heard so far, it sounds as though secureware is one
of the more useless C2 systems.  it's a shame SCO didn't make it a
separate product as AT&T did with their System V/MLS product, or less
intrusive as IBM did with their AIX Version 3 product.  security
features which are properly implemented are quite helpful, and in my
humble opinion, can really make a system much more user friendly.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson