| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 594.1 | | EVMS::KILGALLEN | ZK0 4x13, DTN 381-2879 | Wed May 14 1997 13:28 | 16 |
| > <<< Note 594.0 by ACISS2::LENNIG "Dave (N8JCX), MIG, @CYO" >>>
> If the application (X and Y) is on one disk, and the objects being
> accessed by Y are on another, which volumes need to be mounted with
> the /subsystem qualifier?
The application disk.
The effect of mounting a volume with the /subsystem qualifier is to
say that the operating system is to trust any ACLs on the disk which
ascribe subsystem identifiers to programs. Otherwise, I could bring
a disk to your system which I had doctored on my system to give me
access.
The regular access ACLs which are (presumably) protecting the data
files have no need for special trust safeguards.
|
| 594.2 | INSTALL and subsystem identifers: executable images only | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Wed May 14 1997 14:55 | 12 |
|
Shareable images cannot have subsystem identifiers, nor can they be
installed with privileges -- these are security attributes only valid
in conjunction with executable images.
The only sort of "shareable image" that can grant additional system
access -- access beyond that directly authorized to the user -- is a
user-written system service (UWSS), sometimes refered to as a privileged
shareable image. The code in a UWSS can grant additional system access
by execution in executive or kernel mode.
Beyond this little snag, Larry's answer stands.
|
| 594.3 | | ACISS2::LENNIG | Dave (N8JCX), MIG, @CYO | Wed May 14 1997 15:06 | 6 |
| Damn. Would have been a good solution to a problem I have.
I'm surprised that the image activation done by lib$fis excludes
the "adoption" of the subsystem rights identifiers.
Dave
|
| 594.4 | Image Activation Is Recusive; Only First Pass Gets Privs | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Wed May 14 1997 17:04 | 20 |
|
: I'm surprised that the image activation done by lib$fis excludes
: the "adoption" of the subsystem rights identifiers.
Only the parent (executable) image gets the extra access -- all
subsequent "constituent" (shareable) image activation calls,
including user calls to the image activator made via
lib$find_image_symbol, are processed as "constituent" shareable
images.
There is a long-standing oddity in this area -- the image activator
enters a "paranoid" image activation mode if a constituent shareable
image is (mistakenly) installed with privileges or subsystem
identifiers. This behaviour is correct for executable images,
but this is not necessary for shareable images. This does not
affect the access granted by the shareable image (none), but this
does affect the behaviour of things such as the acceptance of
non-privileged logical name redirection and <CTRL/Y> rundown
(DEBUG) handling.
|
| 594.5 | | AUSS::GARSON | DECcharity Program Office | Wed May 14 1997 23:12 | 9 |
| re .3
If activating a shareable image that is INSTALLed with privs granted
additional access then security would be compromised. I could write a
main program that links against the shareable image but which happens
not to use anything in the shareable image and just uses the additional
access. The same consideration applies to subsystem rights.
Describe your problem.
|
| 594.6 | | ACISS2::LENNIG | Dave (N8JCX), MIG, @CYO | Thu May 15 1997 00:37 | 16 |
| re: .5
I understand the vulnerability you describe. Note that I said both X
and Y could/would be installed images. Hey, I was hoping...
The problem is that Y needs to access some protected information, and
the method used for the past 10 years or so (installing X with privs)
is no longer an option due to the owners of X changing it's behaviour
wrt installed privs (and refusing to restore it's previous behaviour).
Creating a privileged sharable image Y' would seem to be the obvious
solution, however there would be issues around this approach as well.
I can't really say much more in an open forum. Thanks anyway folks.
Dave
|