How to use SUBSYSTEM ACL's

[Hoff]

Why do disk volumes require explicitly enabling subsystem identifiers?

Um, do you really want a random disk mounted by a user to have the ability to grant subsystem ACL access by default?

Even for a /SYSTEM disk mount, that might not be the most desirable default. (Do you want a MOUNT nuking your system security?)

Ever wondered why Microsoft Windows security keeps getting stomped on? This tool surprised me:

http://technet.microsoft.com/en-us/sysinternals/bb963902

Stuff can be activated from all over the place. And mounting a disk is one of the most common spots you can see an AUTORUN light up.

Well, the subsystem identifier (if enabled by default) would be a more subtle form of the same basic mess.

[Hoff]

ps: Security can be a real problem to maintain when you have trusted and untrusted code mixed together and executing in the same process context, and it's very easy to open up huge holes here.

This is at the core of AUTORUN and subsystem identifiers and any number of other ways that an attacker can (try to) burrow into a trusted application or into the VMS kernel.

It is often best to avoid the combination where you can, and to use separate processes for trusted and untrusted code. This is why auditing and alarms or the REQUEST command or a DECnet task-to-task connection can be useful; you have either OpenVMS code maintaining the separation, or you use processes to maintain separation.

And even with process-level separation of privileges, you still need to handle the parameter-passing or the data sanitization correctly where the trusted and untrusted code meets.

Variations of this attack are known as SQL injection and cross-site scripting, and these are huge problems with web tools.

--

Reposting this reply after having checked for duplicates, as ITRC is being ITRC again today.

[Hoff]

And FWIW, various Unix operating systems will also mount volumes with NOSUID for similar reasons; you usually don't want any "surprises" lurking when you mount a volume.