Bad login user id(sco-unix)

[Eamonn McManus]

In article <18651 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F. Haugh II) writes:
>In article <1990Oct26.092606.7374 at robobar.co.uk> ronald at 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.

To set the record straight, the code for changing the SCO luid was written
by my colleague Charles Bryant <ch at dce.ie>.  It is already a separate
function so the changes to Mr Haugh's login should be minimal.

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

This is probably very hard to do in the context of Unix though.  The
reason I continually criticise the SCO/SecureWare farce is that I
consider that security should be implemented correctly or not at all.
They don't allow the luid to be changed even by root, but root can change
it by poking in /dev/kmem.  Even if root were allowed to change the luid
by the normal means (setluid() call), it could still circumvent auditing
by using /dev/kmem.

I distrust systems with privileges (which SCO has as well) for the same
reason.  There is no point in providing two distinct privileges if you can
somehow use one to gain the other.  In Unix, root can modify any file:
this is so fundamental that arguably a system where it is not true is
not Unix.  Therefore root has all privileges and can circumvent all
auditing by virtue of its ability to change /unix.

It's certainly possible to produce a secure Unix-like system where ability
to do various operations can be parcelled out to different users and where
everything can be audited.  The challenge is to do this in such a way that
it does not interfere excessively with normal system operation, while
being not just hard but impossible to circumvent.  The SCO/SecureWare setup
fails miserably on both counts.

Just in case the point has not been made enough times already, SCO should
realise that many people don't want any more security than the Unix norm
and should make it possible to run that way.
--
Eamonn McManus    <em at dce.ie>		Are they the pearls of song
Dropped by countless angel throng	From paradise above?  No.