Can anyone point to either: - 1) A release Note 2) Something in a "porting guide" 3) Something in the standard docs 4) A secttion from your favourite "Shareable Image Cookbook"
That explains why *on Itanium systems only* VMS requires Read as well as Execute access to a shareable image in order to be able to just execute it?
That's right, I don't want to Link against it, LIB$FIS it, only to [E]xecute it. Just like VAX and Alpha where you only need (W:E) access.
I specifically don't want unprivileged users to be able to link/lib$fis against my RTL (Just like many standard VMS layered products on VAX and Alpha).
I haven't been able to find anyone to acknowledge or own up to this change or its motivation; any ideas?
A reasonable important VMS security regime change don't you think?
I understand lib$fis needs [R]ead access to and shareable image - fine!
I understand the Linker needs [R]ead access to the shareable image - fine!
Why does the image activator need [R] access to the shareable image when it didn't on Alpha or VAX?
Are you (or anyone) not concerned that what was previously explicitly forbidden by having a shareable image set to (W:E) instead of the now (W:RE) is now a barn-door wide open?
VMS/IA64 now *requires* us to adopt a security policy at odds to Alpha and VAX and you're saying "in hindsight it might have been worth a footnote or two"?
Anyone can now LIB$FIS or LINK to RDB$COSIP.EXE and get a free UAF reading password hacker; "Not bovvered"?
This problem was reported for V8.3 and there was a fix. Any ECO with an image_management.exe generated after Dec-2006 should have the fix. The fix is included in 8.3-1H1. If this still shows in such versions, please contact HP.
the problem description from VMS83I_SYS-V0200 looks like this:
5.2.14 Image Activation Failure
5.2.14.1 Problem Description:
If an executable or shareable image is installed, and the user only has execute access to the image file, activating the image fails with a the following error message:
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
For installed images, the image activator maps the file based global sections created by INSTALL. By default, mapping the global section requires read access, which is compared with the protections set for the file. With only execute access granted, the check fails with the NOPRIV error.
It looks like the fix is incomplete. Can you show the output of INSTALL LIST for RDB$COSIP.EXE? Does it say Shared or SharAddr? Can you test with installing it /share=addr? Sorry to insist, but it's time to send a problem report.
Interesting! I agree this would be a very important change (and one that I'd strongly argue against).
It seems to be working correctly for me on OpenVMS V8.3-1H1 on a trivially simple test case. I created a shareable image with a "Hello World" routine, linked a program against it, then set it to (E,E,,) protection. The first program can still activate the image, but TYPE and LINK and LIB$FIS all fail:
$ ty tshr.exe %TYPE-W-OPENIN, error opening DSA1:[GILLINGS]TSHR.EXE;1 as input -RMS-E-PRV, insufficient privilege or file protection violation $ link main1+sys$input/opt tshr/share %ILINK-F-OPENIN, error opening DSA1:[GILLINGS]TSHR.EXE;1 as input -RMS-E-PRV, insufficient privilege or file protection violation $ run fis %LIB-E-ACTIMAGE, error activating image DSA1:[GILLINGS]TSHR.EXE;1 -SYSTEM-W-ACCONFLICT, file access conflict %TRACE-E-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC LIBRTL LIB$FIND_IMAGE LIB$FIND_IMAGE_SYMBOL 1812 0000000000002800 FFFFFFFF841BC750 FIS 0 0000000000020092 0000000000020092 0 FFFFFFFF80C48192 FFFFFFFF80C48192 DCL 0 000000000006BD22 000000007ADB7D22 %TRACE-I-END, end of TRACE stack dump %SYSTEM-W-ACCONFLICT, file access conflict
RDB$COSIP.EXE is a red herring. I just set it to W:E and was still able to SQL$ and to specify username/pass in the database attach spec. Why they deliberately set it to W:RE on Itanium only they know but I submit it should be W:E only. (I guess they just had to do it to get Itanium out the door?)
Mine is less of a security risk as "correctness" so I'm looking at W:RE on t3$private too, but I will try for a small reproducer . A common and protected PSECT is shared between the two which could be the first port of call.
$ set proc/priv=(noall,tmpmbx,netmbx) $ mc sql$ SQL> attach 'file mf_personnel user ''tier3_dev'' using ''xxx'''; %SQL-F-ERRATTDEC, Error attaching to database mf_personnel -RDB-E-UNAVAILABLE, Rdb/Dispatch is not available on your system -RDB-I-TEXT, %LIB-E-ACTIMAGE, error activating image RX2600$DKA100:[SYS0.SYSCOMMON.][SYSLIB]RDB$COSIP.EXE, -SYSTEM-F-NOPRIV, insuffi cient privilege or object protection violation
Sorry, I can't run your test - policy regarding privileged programs (if it were an Alpha question I could run it on my home Alpha, but I don't have an IA64 to play with).
The issue may have something to do with the /PROTECT on the installed image, or maybe it's because of the two levels? As a sanity check, could you please try the attached procedure to see if my trivial example works correctly? No kernel mode code, no privilege required. Worst it will do is leave a few files and some logical names defined.
$ @john This should output "Hello World" Hello World This should output "Hello World" again Hello World This should fail with %TYPE-W-OPENIN %TYPE-W-OPENIN, error opening DKA0:[TIER3_DEV.GILLINGS]TSHR.EXE;1 as input -RMS-E-PRV, insufficient privilege or file protection violation This should fail with %ILINK-F-OPENIN %ILINK-F-OPENIN, error opening DKA0:[TIER3_DEV.GILLINGS]TSHR.EXE;1 as input -RMS-E-PRV, insufficient privilege or file protection violation This should fail with %LIB-E-ACTIMAGE %LIB-E-ACTIMAGE, error activating image DKA0:[TIER3_DEV.GILLINGS]TSHR.EXE;1 -SYSTEM-W-ACCONFLICT, file access conflict %TRACE-E-TRACEBACK, symbolic stack dump follows image module routine line rel PC abs PC LIBRTL LIB$FIND_IMAGE LIB$FIND_IMAGE_SYMBOL 1812 0000000000002800 FFFFFFFF841BC750 TFIS 0 0000000000020092 0000000000020092 0 FFFFFFFF80B9E492 FFFFFFFF80B9E492 DCL 0 000000000006BD22 000000007AE27D22 %TRACE-I-END, end of TRACE stack dump %SYSTEM-W-ACCONFLICT, file access conflict
The ECO talks about installed images. It talks about mapping global sections. If installed /share, it gives the error, if installed /share=addr it works. The fix is incomplete, it addresses only /share=addr, which the error report was for. Please report the problem to get the fix.
You're an absolute champion! Should have given your post 10 points.
> if installed /share=addr it works.
Sure does! Can't think of hand why you wouldn't use share=ADDRESS as opposed to vanilla /SHARE but is sounds better than setting protection down to w:Re so I'm off to investigate.
> Please report the problem to get the fix.
Not in a position to do that at the mo, and if Rdb Engineering can't be bothered then it can't be too important :-(
But maybe you can find the guy at VMS responsible who considers regression-testing a clean-compile and Linker-errors a manufacturing issue and get him/her to be a bit more pro-active?
OK, I'll try to find that guy who only made minimal (security related) changes when he took over the image activator (which some people name a complex environment). If nobody wants this fixed in an ECO, it will go into the next major release.
Yes, I want it fixed in an ECO, justice *demands* it is fixed in an ECO!
Don't you dare sit there as an appologist for the incompetent that made the original change and ask me to jump through hoops :-(
But as I summed it up recently in a note to the Rdb Listserver: -
----- Original Message ----- From: Richard's Hotmail To: oraclerdb@jcc.com Sent: Friday, February 13, 2009 10:40 AM Subject: Re: IA64 and protection on RDB$COSIP.EXE
In closing: -
- /SHARE=ADDRESS_DATA is starting to look like the mutt's nuts to me (although I too could have lowered the power to the sheilds and set protection to W:RE with far less security implecations in my case.)
- No one here seems too worried that anyone can now LINK or LIB$FIS to RDB$COSIP and chance their arm at some passwords. (I'd take Port Number out of the intrusion detection just in case too)
- I don't have a support agreement nor the rapport you share between VMS and Rdb engineering
As an annoying developer who used to sit across from me had a habit of solutionizing "Someone oughta do something!" :-)
Cheers Richard Maher
----- Original Message ----- From: Norman Lastovica To: oraclerdb@jcc.com Sent: Friday, February 13, 2009 9:15 AM Subject: RE: IA64 and protection on RDB$COSIP.EXE
If there is a problem on VMS, Please do get in touch with HP OpenVMS support directly and they should be able to help you.
From: Richard's Hotmail Sent: Thursday, February 12, 2009 6:48 PM To: oraclerdb@jcc.com Subject: Re: IA64 and protection on RDB$COSIP.EXE
Hi Norm,
Thanks for the reply!
It is a bug, but a VMS/IA64 image-activator bug (that wasn't completely fixed) rather than and Rdb kitting bug. Let me illustrate on my lovely RX2600 VMS/IA64 8.3-1H1: -
$ set file/protect=w:e sys$library:rdb$cosip.exe $ set proc/priv=(noall,tmpmbx,netmbx) $ mc sql$ SQL> attach 'file mf_personnel user ''tier3_dev'' using ''xxx'''; %SQL-F-ERRATTDEC, Error attaching to database mf_personnel -RDB-E-UNAVAILABLE, Rdb/Dispatch is not available on your system -RDB-I-TEXT, %LIB-E-ACTIMAGE, error activating image RX2600$DKA100:[SYS0.SYSCOMMON.][SYSLIB]RDB$COSIP.EXE, -SYSTEM-F-NOPRIV, insuffi cient privilege or object protection violation SQL> exit
My problem with someone on your side is they they've arbitrarily chosen to just drop the protection on the image rather than pursue VMS Engineering to fix the problem :-(
The work around for Tier3 appears to be to simply install the T3$PRIVATE.EXE and T3$PUBLIC.EXE shareables with the /SHARE=ADDRESS option in the install utility. It would also appear from the following example that this option is not available to RDB$COSIP.EXE: -
I guess you are comparing your DIR_WATCH_EXEC utility with the recently updated WatchDir from Jim Duff as they appear to perform the same function?
Perhaps you can open a specific thread about that and indicate if there are any particular attributes of the utilities that you wish people to compare? Robustness, ease of use, documentation, that sort of thing?
