[Info-vax] The best VMS features, was: Re: openvms renaming file

[Arne Vajhøj]

On 5/28/2018 4:33 PM, Simon Clubley wrote:
> On 2018-05-28, Johnny Billquist <bqt at softjar.se> wrote:
>> On 2018-05-28 21:15, Simon Clubley wrote:
>>> On 2018-05-28, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>>> On 5/28/2018 1:56 AM, Simon Clubley wrote:
>>>>> For one obvious example, what exactly is the point of having both
>>>>> CMEXEC and CMKRNL privileges on VMS, given how VMS is designed ?
>>>>>
>>>>> Because of that design, CMEXEC is completely and utterly redundant
>>>>> and is just artifical complexity (and a false sense of security).
>>>>
>>>> I don't think it is.
>>>>
>>>> It was never intended to be a security feature where getting from EXEC
>>>> to KRNL required something special.
>>>>
>>>> But it did and still does provide two levels of access for code,
>>>> that protects against coding errors (but not against malicious code).
>>>>
>>>
>>> All you need to do is to give the user or program CMKRNL privilege and
>>> let the program switch into executive mode instead because when you
>>> give the user or program CMEXEC privilege, what you are really giving
>>> them is CMKRNL privilege.
>>>
>>> CMEXEC is utterly redundant within VMS as currently implemented.
>>
>> How about you actually listen and understand what someone said? The use
>> case Arne brought up is perfectly valid.
> 
> I understood what Arne said - he's missed what I am saying. You don't
> need CMEXEC privilege to get into executive mode. You can do it with
> CMKRNL privilege:
> 
> http://h41379.www4.hpe.com/doc/84final/4527/4527pro_017.html
> 
> and further more, if you can switch into executive mode with CMEXEC
> privilege you can also get into kernel mode without needing CMKRNL
> privilege. From the above URL:
> 
> |For example, $CMKRNL bypasses the check for CMKRNL privilege that is normally
> |required when $CMKRNL is called from executive mode, and $SETPRV calls are
> |processed without SETPRV privilege when called from executive or kernel mode.
> 
> Like I said, CMEXEC privilege is completely and utterly redundant
> within VMS as currently implemented.

If we agree that there are valid reasons to have both EXEC and
KRNL mode, then let us get to whether we need two privs CMEXEC
and CMKRNL or just one CMKRNL.

De facto then both CMEXEC and CMKRNL implies full privs. So
there is no security difference.

But there can be other reasons.

Protection against mistakes. If some code is supposed
to only call SYS$CMEXEC but not SYS$CMKRNL and only
get granted CMEXEC then it will actually fail if it
mistakenly calls SYS$CMKRNL.

(malicious code could call SYS$CMEXEC and then
SYS$CMKRNL but we are talking buggy code not
malicious code here)

Encapsulation. If the rule about EXEC mode
always allowing SYS$CMKRNL was ever changed, then
having two privs will save a lot of spillover
changes.

Documentation. CMEXEC priv to call SYS$CMEXEC and
CMKRNL priv to call SYS$CMKRNL is sort of easy
to remember. CMKRNL priv to call SYS$CMEXEC is
a bit confusing.

Arne