Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

ACL Question.

 
SOLVED
Go to solution
The Brit
Honored Contributor

ACL Question.

Hi Guys,
Just seeking understanding here.

It is my understanding that ACE's in an ACL are read sequentially from the top, and than once an ACE is found which EXPLICITLY allows, or denies the requested access, then the system stops reading the ACL at that point and allows/denies access to the user.

Is this correct?

So, if I had an ACL resembling the following

FILENAME.EXE
(IDENTIFIER=*,ACCESS=NONE)
(IDENTIFIER=FRED,ACCESS=READ+WRITE)

then the second ACE becomes irrelevent since the first line explicitly denies access. (This assumes that there is no access through the protection string, and the user does not have elevated privileges.)

Am I correct here??

Thanks in advance.

Dave.
9 REPLIES 9
Volker Halle
Honored Contributor
Solution

Re: ACL Question.

Dave,

you're right. See the details in the 'HP OpenVMS Guide to System Securty':

-> Security for the User
--> Protecting Data
---> How the System Determines If a User Can Access a Protected Object

http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/aa-q2hlg-te.HTMl

Volker.
John Gillings
Honored Contributor

Re: ACL Question.

Dave,

I'd word it differently... we search for the the first ACE that matches the users Object Rights Block. So there are no cases which will read beyond a wildcard identifier in an ACE.

The SOGW protection mask is only considered if you "fall off" the end of the ACL, or have one of the bypass category privileges. Since you can't "fall off" the ACL, if there's a wildcard, it makes no difference. So, generally speaking, the only sensible place for IDENTIFER=* is at the end of the ACL.

Follow Volker's link and look for "Figure 3 Flowchart of Access Request Evaluation"
A crucible of informative mistakes
Jan van den Ende
Honored Contributor

Re: ACL Question.

Dave,

the previous answers are correct, and SHOULD be the whole story.

However, there is some more.
When accessing the system via FTP, the FTP software apparently FIRST checks access right, before turning control over to RMS.
BUT, since FTP is essentially an U*X functionality, the access check ONLY considers the U*X "Access Control List", as in U*X speak for the RWX access for the OGW categories.

So, if you intend to grant some access only to holders of some identifier, the RMS --protection mask-- (WITHOUT the System group, and the Delete access) should allow that access, and only after that, you should fine-tune the restrictions using (RMS) ACLs.
(Note that this also precludes System access via the GRPPRV privilege).

Note:
I have only pertinence on this for UCX V4.x and HP TCPIP services for OpenVMS V5.1.

I never had a reason to investigate later versions, nor did I have other IP stacks available to check.
I have not tried other networking protocols like NFS.
The above explicitly does NOT pertain to DECnet IV, V, nor DECnet-over-IP, nor AS-over-IP.

hth

Proost.

Have one on me.

jpe

Don't rust yours pelled jacker to fine doll missed aches.
The Brit
Honored Contributor

Re: ACL Question.

Thanks for your replies guys.

Just to respond to Johns observation, the directories which hold our code assign several "default" ACE's to new files created in the directory. The deployment then assigns a "SUBSYSTEM" ACL.

The point being that I don't want to have to interfere with the existing deployment code, I simply want to modify a single exe so that its use is restricted to holders of a specific Rights Identifier. for example, a typical exe looks like


PROGRAM.EXE;2 21/73 12-JUN-2005 11:52:39.32 [SYSTEM] (RWED,,,)
(SUBSYSTEM,IDENTIFIER=DATA_WRITE,ATTRIBUTES=NONE)
(IDENTIFIER=APP_CONTROL,ACCESS=READ+WRITE+DELETE+CONTROL)
(IDENTIFIER=APP_READ,ACCESS=READ)
(IDENTIFIER=APP_SPECIAL,ACCESS=READ)
(IDENTIFIER=APP_RUN,ACCESS=READ)

where the last 4 ACL's are defaults, and the SUBSYSTEM ACL is added by the deployment process.

I intend to modify the ACL to look like;

PROGRAM.EXE;2 21/73 12-JUN-2005 11:52:39.32 [SYSTEM] (RWED,,,)
(SUBSYSTEM,IDENTIFIER=DATA_WRITE,ATTRIBUTES=NONE)
(IDENTIFIER=, ACCESS=READ)
(IDENTIFIER=*,ACCESS=NONE) (IDENTIFIER=APP_CONTROL,ACCESS=READ+WRITE+DELETE+CONTROL)
(IDENTIFIER=APP_READ,ACCESS=READ)
(IDENTIFIER=APP_SPECIAL,ACCESS=READ)
(IDENTIFIER=APP_RUN,ACCESS=READ)

Now, if my understanding is correct, and taking into account the previous comments, then the image will stay in the SUBSYSTEM group, but ONLY users with will be able to execute it. (I know I could remove the default ACE's, but I don't think it is necessary).

Any additional comments welcome.

Dave.
The Brit
Honored Contributor

Re: ACL Question.

This is for John!

I have been looking closely at the "Flowchart of Access Request Evaluation" in the Guide to System Security, and I see what looks like a contradiction to your post.

Your contention is that a wildcard ACE will stop the Access evaluation, however that doesn't appear to be how the flowchart reads...

Box 1 "is there a matching ID ACE"

(and here I assume that a "wildcard" constitutes a match.) then take the "YES" path.

Box 2 "does the ACE grant the requested access..." Answer = NO, Goto BB.

"BB" now goes on to examine ownership and protection strings to see if access can be allowed.

Am I reading this wrong??

Dave
Jan van den Ende
Honored Contributor

Re: ACL Question.

Dave,

>>>
(SUBSYSTEM,IDENTIFIER=DATA_WRITE,ATTRIBUTES=NONE)
(IDENTIFIER=, ACCESS=READ)
(IDENTIFIER=*,ACCESS=NONE) (IDENTIFIER=APP_CONTROL,ACCESS=READ+WRITE+DELETE+CONTROL)
(IDENTIFIER=APP_READ,ACCESS=READ)
(IDENTIFIER=APP_SPECIAL,ACCESS=READ)
(IDENTIFIER=APP_RUN,ACCESS=READ)

<<<

Apply the logic you outlined yourself for any of the APP_* Idents.

First: .. does not apply
Second: * .. applies to everyone. ACCESS=NONE => end of list scanning.

The APP_* idents never get tested.

In EVERY case where you want to use IDENT=*, that entry -- IS THE LAST ONE tested, so to make the others relevant, IDENT=* must FOLLOW them, ie, be the last in the ACL.

(but OPTIONS=DEFAULT is a separate category, so that has its own list-of-first hit)

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
The Brit
Honored Contributor

Re: ACL Question.

Jan,
I agree with both you and John, the wildcard ACE effectively stops the reading of the ACL, however it doesn't necessarily stop the Access Evaluation Process.

See my last post above. It appears that unless access is granted in the ACL, then it will always proceed to the ownership, protection string and finally privilege evaluation to deter whether access is ultimately allowed.

Or am I wrong? (wouldn't be the first time)

Dave.
Jan van den Ende
Honored Contributor

Re: ACL Question.

Dave,

Yes, after the ACL does NOT grant access, then the OWNER field is evaluated. If still no access, then the SYSTEM field is evaluated against GRPPRV combined with UIC group membership, and finally SYSPRV, and BYPASS.
But the GROUP and WORLD protection masks access are NOT taking into account after an explicit denial.

It IS in the System Security Manual, but the language is not entirely human-friendly: it is more like a legal formulation, exactly specifying the boundaries of allow vs. disallow.

hth

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
The Brit
Honored Contributor

Re: ACL Question.

Thanks for your input guys. Have a great weekend.

Dave.