Path: news.mitre.org!blanket.mitre.org!news.tufts.edu!usenet.logical.net!nntprelay.mathworks.com!news.mathworks.com!mvb.saic.com!info-vax From: Gotfryd Smolik Newsgroups: comp.os.vms Subject: Re:[4] Spawn priveleged processes Message-ID: Date: Fri, 9 Jan 1998 15:09:39 +0100 (MET) Organization: Info-Vax<==>Comp.Os.Vms Gateway X-Gateway-Source-Info: Mailing List Lines: 141 Excuse for appending the relevant citate after message but here are [short, most cuts] are from three mail and also all threads is available. Then : 1. Jan - no, its O:RWED where is the real problem !! If we force a privilege to any job of the owner he can from *another* job modify environment of the privileged :( And for blocking the possiblite I am (in the long mail) propose the SET SECURITY/OWNER and "a must" of enabled privileged (any time) in the subprocess. 2. John, your're right and won the round. Moving the control (of logicals) to the program where creates the privileges subprocess (looks as you this do - from your private mail) is a resolution but isn't short and must be carefully done. Then after long turn of the subprocess possiblity we may run to the old and good resolution with privileged OBJECT in DECNET :) Probably (but haven't test any time) a similiar job can be set in TCP... The disadvantege is that the network must be run - but if that is acceptable then we got what we want. The point from Jan is then used "create new job to ignore the LNM$JOB" but R/DETA don't resolve it in the time of creation: OBJECT run is controlled by system and we don't must run themself the job for checking. Supose we have a "protected" (like CAPTIVE) procedure USERDIR:CAPTPROC.COM. If only command-line interface is enought then a modification of the TELL.COM to make it CAPTIVE ready (the server, not the client side !!) with privileged OBJECT is enought. If anyone must use screen-oriented acces then: 1. Must be created a privileged specialized usename (be aware: with another UIC !). For example: UAF> COPY SYSTEM PRVUSER/UIC=[2,4]/PRIV=SETPRV/DEFP=ALL - /NOPWDEXP/PASS=TYUINHF/NOACCE UAF> MODIFY PRVUSER/ACCES=NETWORK ! Only :) 2. Must be created a OBJECT, b.ex.: NCP> SET OBJECT EXMPL NUMBER 254 ! Also all as DEFINE if permanent !! NCP> SET OBJECT EXMPL USER PRVUSER PASSWORD TYUINHF NCP> SET OBJECT EXMPL FILE CAPEXM.COM and the command file SYS$SYSTEM:CAPEXM.COM as: $ ON ERROR THEN GOTO ATEND $ OPEN IO SYS$NET ! To prevent error in the client side $ READ IO TERMINAL $ terminal="_"+(terminal-"_"-":")+":" ! Not neccessary :) $ WRITE IO "Wait for starting the app." $ IF F$GETDVI(terminal,"DEVCLASS").ne.66 then goto abort $ user:='f$getjpi(F$GETDVI(terminal,"PID"),"USERNAME")' $ IF F$TRNLNM("SYS$REM_ID","LNM$JOB").nes.user then goto abort $! Ok. The exact terminal isn't check, but *this* looks enough ! $ SPAWN/INP='terminal'/OUT='terminal' @USERDIR:CAPTPROC $ATEND: $ CLOSE IO $ EXIT $ABORT: $ write io "Connection aborted due do security check" $ goto ATEND ----------------------- Client (the non-privileged user) side execute a procedure: $ open/read/write io 0"prvuser"::"exmpl=" $ write io f$trnlnm("TT:") $ type io ! Here will wait !! $ close io $ exit Hm.... Also isn't short :) Regards for all - Gotfryd -- the citate---- On 8 Jan 1998, John Briggs wrote: [cuts without notice in tne part] +We're talking about privileged spawn and defenses for LNM$JOB. +(Gotfryd:) +> BUK::GS> def/job loginout mail +Nice try. It was my first try as well. But that's the wrong logical name. + +Gotfryd goes on to explain his theory of inner mode logical names +in the context of SPAWN. His theory is wrong. Definitely. I've wrong not only of the name but of the idea :( Aghr :( + SYS$CREPRC ( , "SYS$SYSTEM:LOGINOUT.EXE",... ) + +And "LOGINOUT" is not presented for logical name translation. +"SYS$SYSTEM" is. + +The game is afoot. I warn you all. I'm good at it. Your won the round. But also for the mail: --- +From: John Briggs +To: Info-VAX@Mvb.Saic.Com ... +In article [cut], Jan Vorbrueggen + writes: [cut] +> OK. Then don't create a subprocess that necessarily shares the +> potential attacker's job table, create a detached process. + +OK. Let's do that. Now how are you going to protect the new process's +job logical name table? --- end of included part ------------------------------------- also the next: ============================================== =From: Jan Vorbrueggen =To: Info-VAX@Mvb.Saic.Com = =Duh. Are you telling me the protection default for job logical name =tables (presuming you can actually _find_ the one you're targetting - =it's not easy) is W:RW? That sure looks like security loophole that =should be closed. = = Jan Regards - Gotfryd -- ===================================================================== $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - THEN EXCUSE/OBJECT=ME $! GS@stanpol.zabrze.pl =====================================================================