ronald@robobar.co.uk (Ronald S H Khoo) (09/20/90)
Can anyone think of any breaches of unix levels of security if one were to simply leave the login uid as zero ? The silly authorisation system seems to look only at the luid but the normal Unix checks seem to apply to the normal (e)uid so it seems to me that if the luid were simply always set to zero (by replacing /bin/login, I guess) then we would effectively have just normal Unix behaviour. Have I overlooked something obvious ? If not, I wonder if SCO can be persuaded to supply such a replacement /bin/login :-) (or someone go and sneak this into their distribution masters <evil grin> :-) :-)) -- my .signature is on holiday
em@dce.ie (Eamonn McManus) (09/21/90)
In article <1990Sep20.163355.7147@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >Can anyone think of any breaches of unix levels of security if one >were to simply leave the login uid as zero ? The silly authorisation >system seems to look only at the luid but the normal Unix checks seem >to apply to the normal (e)uid so it seems to me that if the luid were >simply always set to zero (by replacing /bin/login, I guess) then we >would effectively have just normal Unix behaviour. I don't think you've realised just how cretinous a misfeature the SCO login uid is. Several programs, such as crontab and at, will refuse to run if your login uid is not the same as your real uid. So if you log in as root and su to another user such as news, you can't do crontab -l. To get around this and other SCO idiocies we have rewritten su at Datacode so that it sets the login uid as well as the normal uid to the new user. Of course the setluid() system call won't let you do this even if you're root, but root can poke around in /dev/kmem to accomplish the same effect. If anyone would like a copy of this su, mail me. If there is enough interest, I will post it. -- Eamonn McManus <em@dce.ie> <em%dce.ie@cunyvm.cuny.edu> Fingers are for fuguing.
ronald@robobar.co.uk (Ronald S H Khoo) (09/23/90)
In article <1990Sep21.143435.9810@dce.ie> em@dce.ie (Eamonn McManus) writes: > I don't think you've realised just how cretinous a misfeature the SCO > login uid is. Several programs, such as crontab and at, will refuse to > run if your login uid is not the same as your real uid. Do you have a canonical list of such unhelpful programs? Maybe it's time to collect PD implementations/rewrite these programs and put together the "Official USENET AntiSecureWare for SCO Unix Kit" ? Preliminary list of requirements: i) perform all the functions of the SCO equivalent (other than the SecureWare cr*p) with the same syntax so it becomes a drop-in replacement. ii) be available under terms similar to the Berzerkeley Networking code, or freer. > To get around this and other SCO idiocies we have rewritten su at Datacode > so that it sets the login uid as well as the normal uid to the new user. > Of course the setluid() system call won't let you do this even if you're > root, but root can poke around in /dev/kmem to accomplish the same effect. Hehehehehehehehe ! I *like* this one! Candidate no. 1 for the Official Kit! > If anyone would like a copy of this su, mail me. If there is enough > interest, I will post it. Please do post. I'll install it within 30 seconds of receipt at this site :-) Now, do we have the NSA on our backs for the rest of the century? :-) -- my .signature is on holiday
chip@tct.uucp (Chip Salzenberg) (09/23/90)
According to ronald@robobar.co.uk (Ronald S H Khoo): >Can anyone think of any breaches of unix levels of security if one >were to simply leave the login uid as zero ? ... then we >would effectively have just normal Unix behaviour. Sorry. There are many system utilities that still care about the subsystem databases in /etc/auth/subsystems. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
paul@tetrauk.UUCP (Paul Ashton) (09/25/90)
I originally sent this to comp.unix.xenix.sco but the distribution was eunet, however it may be useful. --- In article <2434@maestro.htsa.aha.nl> fransh@maestro.htsa.aha.nl (Frans van Hattem) writes: >I'm trying to use 'ct' under SCO UnixV.3.2 but it won't work?; :-( >Everything goes well, but when I have to login again (after I'v been called back) I get an error: > "Bad login user id" When login runs it expects to be able to call setluid(S) to set the immutable login user id, which can never after be changed. Unfortunately since your luid has already been set, this will fail and bomb out. The only solution would seem to be (this is what you also need to do if you kill cron off and restart it) :- add a line to /etc/inittab (and /etc/conf/cf.d/init.base) nolu:a:once:/bin/sh < /dev/tty01 >/dev/tty01 2>&1 then on tty01 as root type "init a;sleep 60" you will then have an interactive shell with no luid so you can then try running your ct. --- some other points to add since I sent that:- In the release notes, it does say that ct does not work yet. With no luid you can su to anyone at all and spawn other processes (don't forget you've only 60 seconds!). However the point is that since root has unbridled control of the system, there is no point in preventing a process with an euid of 0 performing setluid. Once you are root you can cover up *ANY* tracks at all (unless there are hardware audits, such as hardcopy printers or one-way comms links) so why try and pretend that you can audit the initial login id of a process that became root? You can't. -- Paul
steve@altos86.Altos.COM (Steve Scherf) (09/26/90)
In article <738@tetrauk.UUCP> paul@tetrauk.UUCP (Paul Ashton) writes: >In article <2434@maestro.htsa.aha.nl> fransh@maestro.htsa.aha.nl (Frans van Hattem) writes: >>I'm trying to use 'ct' under SCO UnixV.3.2 but it won't work?; :-( >>Everything goes well, but when I have to login again (after I'v been called back) I get an error: >> "Bad login user id" > >When login runs it expects to be able to call setluid(S) to set the immutable >login user id, which can never after be changed. Unfortunately since your >luid has already been set, this will fail and bomb out. In Altos Unix, if you have C2 relaxed you can call setluid() as often as you want. The annoying thing is 'ct' still doesn't work! (for other reasons) I don't understand why they even bother to ship a utility that will never work. -- Steve Scherf steve@Altos.COM ...!{sun|sco|pyramid|amdahl|uunet}!altos!steve These opinions are solely mine, but others may share them if they like.