Mailbox protection

[Wim Van den Wyngaert]

I don't seem to find where the RWPL protection of mailboxes is documented (RW is easy but the other 2). Anyone ?

Is there a way to change the protection of audit_mbx (set audit/list) ? The default is "allow all", thus anyone can manipulate it.
I know I could do it after the set auduit/list with set sec but this requires a program change in my case, and that I want to avoid.

Wim

[Wim Van den Wyngaert]

Oh yes : I don't want to change the global default mailbox protection. Not even for a second.

Wim

[Ian Miller.]

The MBDRIVER treats IO$_WRITE/READPLBK, READLBLK, READVBLK all the same so I don't think P,L protection bits make any difference. They may for other functions (SENSMODE, SETMODE).

Your issue is that non-priv users potentiall could read this mailbox?

I think you need to specify the correct protection when the mailbox is created or use SET SECURITY.

[Wim Van den Wyngaert]

Ian : my question is "where is this RWPL documented".
And yes, my issue is that anyone can manipulate the mailbox.
I hope their is some kind of (undocumented)logical to alter the audit mailbox creation behaviour.

Wim

[Ian Miller.]

Section 4.1.3 of the I/O users Manual documents mailbox protection.

[Wim Van den Wyngaert]

Not exactly what I was looking for.

This did : help set sec /prot.

A list of what protection codes exist (object class device indicates a mailbox. May be this was choosen too general ?).

Wim

[Hoff]

Do take a look at the Security Manual, in the region of Chapter 5 entitled Device Protection.

There are a couple of pages of details there.

The bits for shared devices are defined as:
Read, Write, Physical, Logical, Control. Unshared devices include Read, Write and Control.

If you fire up the search box on the PDF, there are numerous references to mailboxes within the security manual. Mostly located within the pages 92 and 96 in the V7.3-2 edition that's presently current.

ACLs are (an)approach here for protecting a device, though having an audit mailbox exposed in the fashion described looks to be a security bug, and one that appears worthy of a formal report. I'd hope that only suitably privileged users would be able to access and to read the mailbox and its data.

[Ian Miller.]

What is creating the mailbox?
If it's your program then you can control the protection.

[Wim Van den Wyngaert]

I think it is the audit_server process.
My program spawns a "set aud/list". So, I will need to modify it if sox audit requires it.

Wim

[Ian Miller.]

I thought the way that worked is that you create the mailbox then specify its name in the SET AUDIT/LISTENER command?

[Wim Van den Wyngaert]

No. You create it with set audit/listen=audit_mbx where audit_mbx is a logical created by the set command.

Audit_server is signaled that it must use the mailbox. But not sure who executes it : a rtl or audit_server or ??? No file is accessed by setaudit.exe (set watch done).

Wim

[Karl Rohwedder · Accepted solution]

< No. You create it with set
< audit/listen=audit_mbx where a udit_mbx is a
< logical created by the set command.

If I do a SET AUDIT/LIST=MBX I get an invalid device error. To specify a audit-listener mailbox I had to CREATE/MAILBOX mbx and do a SET AUDIT with the MBAxxx device name, specifying MBX leads again to an error (OpenVMS/Alpha V8.3).

regards Kalle

[Ian Miller.]

Wim,
If you create a mailbox (specifying the device protection you require) and then enter a SET AUDIT/LISTENER command specifying the mailbox that you have created then this will give you what you require.

I tried this using OpenVMS Alpha V8.3 CREATE/MAILBOX command.

I think in your case the mailbox is being created by SET AUDIT as it does not already exist and it inherits the default protection.

[Wim Van den Wyngaert]

OOOEEEEPPPSSSS

I didn't notice the crembx in the program (Fortran). That explains everything.

Thanks Kalle & Ian.

Wim