- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: IA64 problem with Shareable Image protection
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-10-2009 04:40 PM
тАО02-10-2009 04:40 PM
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?
Cheers Richard Maher
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-10-2009 05:53 PM
тАО02-10-2009 05:53 PM
Re: IA64 problem with Shareable Image protection
>> I haven't been able to find anyone to acknowledge or own up to this change or its motivation; any ideas?
The motivation is easy... LIB$FIS actually reads the ELF image with RMS $GET calls, before calling the image activation itself.
When you read a file, you need to have read access.
As to documentation, what next, whether it could have been done better, and other silly questions... I don't know and don't care!
Reference:
Facility: LIBRTL
Module: LIBFNDIMG
Function: lib$$read_object
Cheers,
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-10-2009 06:05 PM
тАО02-10-2009 06:05 PM
Re: IA64 problem with Shareable Image protection
I must not be making myself clear :-(
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"?
Cheers Richard Maher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-11-2009 02:23 AM
тАО02-11-2009 02:23 AM
Re: IA64 problem with Shareable Image protection
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-11-2009 03:58 AM
тАО02-11-2009 03:58 AM
Re: IA64 problem with Shareable Image protection
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
Images Affected:
- [SYS$LDR]IMAGE_MANAGEMENT.EXE
- [SYS$LDR]IMAGE_MANAGEMENT.STB
5.2.14.2 CLDs, and QARs reporting this problem:
5.2.14.2.1 CLD(s)
QXCM1000377545
5.2.14.3 Problem Analysis:
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.
This fix is also included in VMS821I_SYS-V0400.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-11-2009 04:21 AM
тАО02-11-2009 04:21 AM
Re: IA64 problem with Shareable Image protection
Thanks for the replies!
Certainly sounds like my problem doesn't it, but why am I still getting it?
Can anyone (including the patch testers) show a working example on 8.3-1H1?
Does anyone have the accompanying release note?
Why did Rdb Engineering just stick their tail between their legs and change RDB$COSIP.EXE to (W:RE)?
Cheers Richard Maher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-11-2009 09:19 AM
тАО02-11-2009 09:19 AM
Re: IA64 problem with Shareable Image protection
Sorry to insist, but it's time to send a problem report.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-11-2009 02:20 PM
тАО02-11-2009 02:20 PM
Re: IA64 problem with Shareable Image protection
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
$ run main
Hello World
We have applied HP I64VMS VMS831H1I_SYS V3.0
Maybe your case is more complex?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-11-2009 02:39 PM
тАО02-11-2009 02:39 PM
Re: IA64 problem with Shareable Image protection
Thanks for the replies!
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.
Cheers Richard Maher
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-11-2009 03:09 PM
тАО02-11-2009 03:09 PM
Re: IA64 problem with Shareable Image protection
$ 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
$dir/full sys$library:rdb$cosip.exe
Directory SYS$COMMON:[SYSLIB]
RDB$COSIP.EXE;1 File ID: (19375,1,0)
Size: 32/32 Owner: [SYSTEM]
Created: 20-NOV-2008 14:21:49.09
Revised: 12-FEB-2009 05:27:09.71 (4)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 32, Extend: 0, Global buffer count: 0, No version limit, Contiguous best try
Record format: Fixed length 512 byte records
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RWED, World:E
Access Cntrl List: None
Client attributes: None
Total of 1 file, 32/32 blocks.
$
A "reproducer" or for some reason would they use lib$fis?
Cheers Richard Maher