ronald@robobar.co.uk (Ronald S H Khoo) (10/26/90)
[ did this thread ever have anything to do with internals ? back to sysv386 now, anyway ... ] halpin@mitisft.Convergent.COM (pri=20 Chris Halpin) writes: > The luid is an additional uid associated w/every process that is set at > login time and CAN NEVER be changed 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. > 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 :-) > exec(2)ing login will result in an attempt > to setluid(2) that fails since the luid is already set. Which is extremely inconvenient since it causes ct(1) to fail. A good reason to switch login(1)s. > creates problems with cron (you need to shutdown to restart cron since it > needs to be run w/no luid set so that is may run its jobs as any user it > chooses). 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. > 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 :-) -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
halpin@mitisft.Convergent.COM (pri=20 Chris Halpin) (10/27/90)
From article <1990Oct26.092606.7374@robobar.co.uk>, by ronald@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.
jfh@rpp386.cactus.org (John F. Haugh II) (10/27/90)
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
em@dce.ie (Eamonn McManus) (10/30/90)
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 <ch@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@dce.ie> Are they the pearls of song Dropped by countless angel throng From paradise above? No.
lws@capybara.comm.wang.com (11/03/90)
I think I missed the beginning of this thread. Did a solution come up
to the problem where {rlogin,telnet,ftp} refuse to let you in because
of "Bad login user id" ? I've found that this happens most often when
the 3c503 driver is installed but the wdn driver is not... I know, that
sounds bizarre. It is bizarre. I guess if I understood more about the
particular manner in which SCO/Locus broke the various involved pieces
with the Obscureware hack I might have a clue at figuring it out myself.
Anybody?
--
Lyle Wang lws@comm.wang.com
508 967 2322 Lowell, MA, USA uunet!comm.wang.com!lws