hliao@opus.calstatela.edu (10/22/90)
>From: opus!hliao (Henry Liao)
Why don't you try "exec login"?
-Henry Liao
California State University, Los Angeles
Networking & Distributed Systems Group
BitNET: hliao@csula.bitnet
InterNET: hliao@{atss,neptune,opus}.calstatela.edu
ATTMAIL: attmail!atss!hliao
ZZZZZZ2307GILLV%MUCSD.BITNET@cunyvm.cuny.edu (10/22/90)
>" No utmp entry, you must login from the lowest shell"
Try `exec login' and it should work, or else hit your EOF (CTRL-D) to logout.
If that doesn't work, try typing `logout' or `exit'. You will then get a normal
<hostname:>login prompt. If you are trying to switch your euid, try `su
login-name'
-2307gillv@vmsf.csd.mu.edu (Bitnet)
-VMS: Just Say No.emanuele@overlf.UUCP (Mark A. Emanuele) (10/23/90)
In article <24816@adm.BRL.MIL>, hliao@opus.calstatela.edu writes: > >From: opus!hliao (Henry Liao) > > Why don't you try "exec login"? > That won't work because of the security "features" included with SCO. -- Mark A. Emanuele V.P. Engineering Overleaf, Inc. 500 Route 10 Ledgewood, NJ 07852-9639 attmail!overlf!emanuele (201) 927-3785 Voice (201) 927-5781 fax emanuele@overlf.UUCP
jfh@rpp386.cactus.org (John F. Haugh II) (10/24/90)
In article <1826@overlf.UUCP> emanuele@overlf.UUCP (Mark A. Emanuele) writes: >In article <24816@adm.BRL.MIL>, hliao@opus.calstatela.edu writes: >> Why don't you try "exec login"? > >That won't work because of the security "features" included with SCO. there is an alleged attempt to port my login suite to SCO UNIX. if you want to join in on the fun, why don't you try to pick up a copy of the sources from an archive site near you. or just wait until the appropriate bodies send their changes back to me to post ... i don't know what all SCO did to UNIX to make it so ornery, so i can't comment on how bizarre the security features in SCO UNIX are. just remember boys and girls - security is your FRIEND! -- 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
halpin@mitisft.Convergent.COM (pri=20 Chris Halpin) (10/25/90)
From article <18633@rpp386.cactus.org>, by jfh@rpp386.cactus.org (John F. Haugh II): > In article <1826@overlf.UUCP> emanuele@overlf.UUCP (Mark A. Emanuele) writes: >>In article <24816@adm.BRL.MIL>, hliao@opus.calstatela.edu writes: >>> Why don't you try "exec login"? >> >>That won't work because of the security "features" included with SCO. > > there is an alleged attempt to port my login suite to SCO UNIX. if > you want to join in on the fun, why don't you try to pick up a copy > of the sources from an archive site near you. or just wait until > the appropriate bodies send their changes back to me to post ... > > i don't know what all SCO did to UNIX to make it so ornery, so i > can't comment on how bizarre the security features in SCO UNIX are. > > just remember boys and girls - security is your FRIEND! SCO UNIX uses Secureware's SMP product. It's a SYSV add-on (not yet certified) that provides a C2 level of trust. login(1) was extensively modified to accomodate the requirements of C2. The most notable is addition is the concept of the luid (login uid) (other hacks include a user defined timeout period and the inclusion of a separate password like configuation file [one per user] that controls the users privs). The luid is an additional uid associated w/every process that is set at login time and CAN NEVER be changed (changes to the kernel include a new system call - setluid()). It is used by the audit trail to allow tracking of changes in identity. The only way to change your luid under SCO UNIX/Securware is to logout and login again. exec(2)ing login will result in an attempt to setluid(2) that fails since the luid is already set. The luid also 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).
boyd@necisa.ho.necisa.oz (Boyd Roberts) (10/26/90)
In article <1646@mitisft.Convergent.COM> halpin@mitisft.Convergent.COM (pri=20 Chris Halpin) writes: >... The only way to change your luid under SCO UNIX/Securware >is to logout and login again. exec(2)ing login will result in an attempt >to setluid(2) that fails since the luid is already set. The luid also >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). The other way to set your luid is to use su(1), in the case where you don't yet have one. I've been bitten by the damn thing once. It just gets in the way. Starting daemon's from rc or the inetd _require_ su to start them if they're going to start calling set[ug]id(2). This `security' is _not_ my `friend'. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
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)
em@dce.ie (Eamonn McManus) (10/26/90)
halpin@mitisft.Convergent.COM (Chris Halpin) writes: >The luid is an additional uid associated w/every process that is set at >login time and CAN NEVER be changed (changes to the kernel include a new >system call - setluid()). ... >The only way to change your luid under SCO UNIX/Securware >is to logout and login again. This is only true if you limit yourself to the official kernel interface. It's perfectly possible and indeed useful to defeat the stupidity of login uids by opening /dev/kmem and changing the value there. We recently posted a replacement su for SCO Unix that does this. The same function could be used in a replacement login or cron. >The luid also >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). Another option is to run cron from /etc/inittab, though this is rather painful to set up. Since cron forks into the background, you have to have a dummy process that init is waiting for; you can then kill both the background cron and this process when you want to restart cron. It's much easier to use a replacement cron. -- Eamonn McManus <em@dce.ie> Charles Bryant <ch@dce.ie>