[Info-vax] Kernel Transplantation

[Mark Berryman]

On 1/11/24 6:45 AM, Simon Clubley wrote:
> On 2024-01-10, Mark Berryman <mark at theberrymans.com> wrote:
>> On 1/10/24 6:40 AM, Simon Clubley wrote:
>>> On 2024-01-09, Lawrence D'Oliveiro <ldo at nz.invalid> wrote:
>>>> On Tue, 9 Jan 2024 14:32:48 -0500, Stephen Hoffman wrote:
>>>>
>>>>> And again, what you are interested here in has been available for many
>>>>> years via Sector 7.
>>>>
>>>> I?m not sure they did a comprehensive enough job. For instance, I remember
>>>> the previous time this came up, reading between the lines in one of their
>>>> case studies, the original customer scenario mentioned using DECnet, but
>>>> that was missiong from the description of the solution.
>>>
>>> DECnet should not be in use in today's security world and a customer
>>> should have been forced away from using DECnet anyway due to external
>>> auditing and security standards.
>>>
>> .
>> .
>> .
>>
>> Hogwash.  DECnet can be made just as secure as any IP communication by
>> simply using IP transports.  A couple of simple examples:
>>
>> 1. Run DECnet phase V.  Use DECnet-over-IP, and encrypt it with IPSEC
>> before it ever leaves your host.  This not only encrypts all of your
>> DECnet traffic but it means that DECnet proxies are now as secure as
>> your IPSEC profile.
>>
>> 1a. If you are running OpenVMS on x86, TCP/IP Services does not
>> currently provide IPSEC and Multinet is not yet available.  However,
>> VMware ESXi does support IPSEC.  You can configure your ESXi host to do
>> the encryption for you.  You just need to do your DECnet-over-IP traffic
>> using IPv6.
>>
>> 2. Run DECnet phase IV.  Install pyDECnet on any host in your LAN that
>> supports python (I use a dedicated raspberry pi).  This will be your
>> DECnet router.  Isolate DECnet traffic to its own VLAN.  All off-LAN
>> DECnet traffic is encrypted by the pyDECnet host, again, likely using IPSEC.
>>
>> More security that this is possible.  If you have a security requirement
>> this doesn't meet, let me know.
>>
> 
> I am amused and saddened that whenever I raise this issue, people immediately
> assume that I am talking about MITM attacks only and address that only.
> 
> The fact is that MITM attacks are only a small part of the attack surface.
> Far more common are attacks against the listening services themselves from
> connections you initiate, not those you intercept.
> 
> For example, in 2) above, how does this address clients on an authorised
> VLAN being able to send malformed packets to a server with an inappropriately
> fully-privileged EVL listener that has a dodgy message parser built into it ?

The only hosts I speak DECnet with are trusted hosts.  No other hosts 
can even reach my DECnet stack to try to probe it.  I suspect this to be 
a common setup.

The purpose of a secure setup is to both make things as difficult as 
possible (but never impossible) to perform any sort of unauthorized or 
inappropriate activity, and to be able to trace it if it happens.  By 
isolating DECnet traffic to its own VLAN, it becomes trivial to monitor 
said traffic and isolate and deal with anything nefarious.

On the other hand, other platforms have had holes in their SSL (i.e. 
encrypted TCP traffic) implementation that made it possible for 
outsiders to take control of that host.  Sadly, because the incoming 
data was encrypted, while it was possible to determine that the event 
happened - tracking it back to its source was either difficult or 
impossible (I can't remember which).  With DECnet however, nothing 
reaches my host that I can't see in the clear.

Also, you are out of date.  EVL is not fully privileged.  It only has 
SYSNAM, OPER, and SYSPRV privileges and its listener only runs in 
unprivileged user mode.
.
.
.
> 
> I also find it amusing that whenever I raise this issue, there is nothing
> in the DECnet world that protects data in motion and you all have to
> suggest a protocol that came from the rival TCP/IP world instead. :-)

So?  IP traffic frequently runs over non-IP pipes to get from point A to 
point B.  In fact, if I'm being pedantic, IP traffic gets nowhere 
without some layer-2 protocol to encapsulate and carry it.

As for me, I don't consider them "rival" stacks.  I use them in parallel 
for different purposes.

> PS: I wonder if, 2 years on, whether VSI has got around to fixing those
> issues in DECnet Phase IV yet ?

Beyond your previously mentioned ability to crash EVL, what issues would 
those be (I'm genuinely curious)?

Mark Berryman