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

[Richard Maher]

On 29-May-18 5:16 AM, Arne Vajhøj wrote:
> 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
> 
> 
> 
> 
> 
> 
> 
Not too mention bring the Process down rather than the System on exceptions