ACL Question.

[The Brit]

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.

[Volker Halle · Accepted solution]

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]

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"

[Jan van den Ende]

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

[The Brit]

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]

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]

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

[The Brit]

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]

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

[The Brit]

Thanks for your input guys. Have a great weekend.

Dave.