XRJJM%CSDR.SPAN@STAR.STANFORD.EDU (John McMahon, (07/12/88)
***> From: "IVAX::IJAH400" <ijah400%ivax.decnet@gold.bacs.indiana.edu> ***> ***> UPGRADE and DOWNGRADE are both listed in STARLET.REQ, they are bits 0 and ***> 1 in the second privilege longword. These are described as "may ***> up(down)grade classification". AUTHORIZE seems to know about these too; ***> at least it will let you give them to a user, but it won't list them out ***> with SHOW. ***> ***> James A. Harvey ***> ijah400@indyvax (bitnet) or ijah400%ivax.decnet@gold.bacs.indiana.edu ***> The DCL command SHOW PROC/PRIV won't let you see them (Although I think it used to) but the DCL Lexical F$GETJPI() will. $ SET PROC/PRIV=ALL Issuing a Write Sys$Output F$GETJPI(0,"CURPRIV") results in a %DCL-W-TKNOVF (Command Element Too Long) error. So we remove some of the privs we do know. $ SET PROC/PRIV=(NOCMKRNL,NOCMEXEC,nosysnam,nogrpnam,noallspool) Now issuing the Write Sys$Output F$GETJPI(0,"CURPRIV") results in all the rest of the known privs, plus UPGRADE and DOWNGRADE being listed. But what are they used for ? Perhaps the VMS "Secure System" package, or whatever it's called ? John McMahon xrjjm%scint.span@star.stanford.edu
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (07/17/88)
***> From: "IVAX::IJAH400" <ijah400%ivax.decnet@gold.bacs.indiana.edu> ***> ***> UPGRADE and DOWNGRADE are both listed in STARLET.REQ, they are ***> bits 0 and 1 in the second privilege longword.... The DCL command SHOW PROC/PRIV won't let you see them (Although I think it used to) but the DCL Lexical F$GETJPI() will. ...But what are they used for? Perhaps the VMS "Secure System" package? or whatever it's called ? Good guess. Yes, they are used in that package (I think it's called SE/VMS); they are part of a non-discretionary access control system. (This is the idea in the government's "unclassified", "sensitive", "secret", "top secret" scheme. If you log in to an "unclassified" account, you can't see anything from a higher level. If you log into a, say, "secret" account, you can see "secret" stuff, but you can't move it into an "unclassified" directory. UPGRADE and DOWNGRADE are rights needed to modify security levels - e.g., to take something "secret" and make it "unclassified", you need DOWNGRADE. There's a lot more to it, but it's not worth going into here.) Nothing in "normal" VMS makes use of the bits for anything, except that for simplicity the trivial routines that examine and display them are part of VMS. Otherwise, SE/VMS would have that much more to patch. Someone also asked about TMPJNL and PRMJNL. They are part of another VMS optional facility, RMS journaling. Again, they don't do anything but get set and displayed. (Actually, I'm not sure if RMS journaling as it actually got implemented actually uses these bits - they may just be holdovers from an early design.) -- Jerry
gkn@M5.SDSC.EDU (Gerard K. Newman) (07/17/88)
From: XRJJM%CSDR.SPAN@STAR.STANFORD.EDU (John McMahon, STX/COBE (x4333)) Subject: Undocumented priv bits... Date: Tue 12 Jul 88 05:33:18-PDT ***> From: "IVAX::IJAH400" <ijah400%ivax.decnet@gold.bacs.indiana.edu> ***> ***> UPGRADE and DOWNGRADE are both listed in STARLET.REQ, they are bits 0 and ***> 1 in the second privilege longword. These are described as "may ***> up(down)grade classification". AUTHORIZE seems to know about these too; ***> at least it will let you give them to a user, but it won't list them out ***> with SHOW. ***> ***> James A. Harvey ***> ijah400@indyvax (bitnet) or ijah400%ivax.decnet@gold.bacs.indiana.edu ***> The DCL command SHOW PROC/PRIV won't let you see them (Although I think it used to) but the DCL Lexical F$GETJPI() will. $ SET PROC/PRIV=ALL Issuing a Write Sys$Output F$GETJPI(0,"CURPRIV") results in a %DCL-W-TKNOVF (Command Element Too Long) error. So we remove some of the privs we do know. $ SET PROC/PRIV=(NOCMKRNL,NOCMEXEC,nosysnam,nogrpnam,noallspool) Now issuing the Write Sys$Output F$GETJPI(0,"CURPRIV") results in all the rest of the known privs, plus UPGRADE and DOWNGRADE being listed. But what are they used for ? Perhaps the VMS "Secure System" package, or whatever it's called ? John McMahon xrjjm%scint.span@star.stanford.edu They are privileges required to change the classification of an object when using the non-discretionary security features of VMS. These features are enabled by the SYSGEN parameter CLASS_PROT. Turning on CLASS_PROT isn't enough; you still have to write some code to deal with the manipulation of classification and integrity information for objects. gkn ---------------------------------------- Internet: GKN@SDS.SDSC.EDU Bitnet: GKN@SDSC Span: SDSC::GKN (27.1) MFEnet: GKN@SDS USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138-5608 Phone: 619.534.5076