Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!tcdcs!dce.ie!em From: em@dce.ie (Eamonn McManus) Newsgroups: comp.unix.sysv386 Subject: Re: Bad login user id(sco-unix) Message-ID: Date: 30 Oct 90 13:16:01 GMT References: <18633@rpp386.cactus.org> <1646@mitisft.Convergent.COM> <1990Oct26.092606.7374@robobar.co.uk> <18651@rpp386.cactus.org> Organization: Datacode Communications Ltd, Dublin, Ireland Lines: 51 In article <18651@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >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. To set the record straight, the code for changing the SCO luid was written by my colleague Charles Bryant . 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 Are they the pearls of song Dropped by countless angel throng From paradise above? No.