Bad login user id(sco-unix)

[pri=20 Chris Halpin]

>From article <1990Oct26.092606.7374 at robobar.co.uk>, by ronald at robobar.co.uk (Ronald S H Khoo):
> [ did this thread ever have anything to do with internals ?  back to sysv386
>   now, anyway ... ]
login(1)? Unix security? Hacking /dev/kmem to circumvent a security feature?
Things specific to SCO UNIX yes, but "internals" for sure.

> 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.

Right. What I should have said is the uid SHOULD NEVER be changed otherwise
you have compromised the TCB (root being trusted and all) by circumventing
security.

> Do you know anyone who has enough disc space to enable auditing ? (1/2 :-)

The government can't buy enough disks.

> How can you restart cron ?  Only from init(8), since any shell you
> get from login(1) will have luid set.... unless you use Eamon's hack
> or if you modify login(1) to notice a special login and give it
> a shell without setting the luid.

Right, you can't restart cron. That's what I said.
Cron typically starts w/no luid set and then uses su(1) to set the luid
to the given user... that is, the command portion of a cron entry has an
"su user" preceding it.

> 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

Right. One of the nicer features about UTS/MLS, is the ability to turn
security off quite easily.  I'm informed that later releases of Secureware's
SMP product will be sold by security feature (you pay by the feature). Perhaps
the ability to easily turn off security.