Offer it free ...

Would be fast to port ...

Wouldn't that boost security until other features can be added?

On 2022-11-16 14:47:56 +0000, Michael C said:

> Offer it free ...
>
> Would be fast to port ...
>
> Wouldn't that boost security until other features can be added?

The basic mandatory access control features were likely hauled across
in the port, as it would be more work and more risk to remove those.

Those in-built features can be enabled (for free) using the CLASS_PROT
system parameter.

There was add-on tooling that was licensed. That add-on tooling
replaced many common OpenVMS apps. But who knows what happened to that
code in the ensuing decades?

More generally, mandatory access controls systems didn't and haven't
sold in sufficient numbers to bother with, and are impractical for most
uses.

Data and connections and info more generally can generally flow from
equal to equal, and upgrade from less to more secure, but in the
downgrade direction not so much.

Most of the folks that wanted those security features ended up buying
multiple system-high boxes, rather than trying to buy and run and
maintain mandatory access controls or multi-level security.

As a foundation for other security enhancement work around adding
sandboxes and pledges and such, sure, the mandatory access controls
might help.

For its reuse, the existing design is limited in terms of the numbers
of secrecy and lowercase-i integrity categories permitted; 64 each.

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/16/2022 9:47 AM, Michael C wrote:
> Offer it free ...
>
> Would be fast to port ...
>
> Wouldn't that boost security until other features can be added?

If mandatory access control is seen as important for security by
customers and potential customers then it would make sense.

But I am skeptical.

The common threats today are just so much different than the
common threats 30 years ago.

Arne

On 2022-11-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/16/2022 9:47 AM, Michael C wrote:
>> Offer it free ...
>>
>> Would be fast to port ...
>>
>> Wouldn't that boost security until other features can be added?
>
> If mandatory access control is seen as important for security by
> customers and potential customers then it would make sense.
>
> But I am skeptical.
>
> The common threats today are just so much different than the
> common threats 30 years ago.
>

One major use is for helping to keep attackers contained after a
compromise occurs.

A good example is SELinux which applies this mindset to (by default)
server processes running on a Linux system.

This approach is still _very_ useful, regardless of how the initial
compromise occurred, and whether it was some new or old technique used
to carry out the initial compromise.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/17/2022 8:12 AM, Simon Clubley wrote:
> On 2022-11-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/16/2022 9:47 AM, Michael C wrote:
>>> Offer it free ...
>>>
>>> Would be fast to port ...
>>>
>>> Wouldn't that boost security until other features can be added?
>>
>> If mandatory access control is seen as important for security by
>> customers and potential customers then it would make sense.
>>
>> But I am skeptical.
>>
>> The common threats today are just so much different than the
>> common threats 30 years ago.
>>
>
> One major use is for helping to keep attackers contained after a
> compromise occurs.
>
> A good example is SELinux which applies this mindset to (by default)
> server processes running on a Linux system.
>
> This approach is still _very_ useful, regardless of how the initial
> compromise occurred, and whether it was some new or old technique used
> to carry out the initial compromise.

But what is the specific scenario?

Vulnerability 1 allows an attacker to change DAC protection
on something that the attacker can then utilize via vulnerability 2,
but MAC would prevent that?

I could happen, but I don't see it as a common scenario.

SELinux is certainly useful and relevant, but it does much
more than SEVMS MAC.

Arne

On 2022-11-18, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/17/2022 8:12 AM, Simon Clubley wrote:
>> On 2022-11-16, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/16/2022 9:47 AM, Michael C wrote:
>>>> Offer it free ...
>>>>
>>>> Would be fast to port ...
>>>>
>>>> Wouldn't that boost security until other features can be added?
>>>
>>> If mandatory access control is seen as important for security by
>>> customers and potential customers then it would make sense.
>>>
>>> But I am skeptical.
>>>
>>> The common threats today are just so much different than the
>>> common threats 30 years ago.
>>>
>>
>> One major use is for helping to keep attackers contained after a
>> compromise occurs.
>>
>> A good example is SELinux which applies this mindset to (by default)
>> server processes running on a Linux system.
>>
>> This approach is still _very_ useful, regardless of how the initial
>> compromise occurred, and whether it was some new or old technique used
>> to carry out the initial compromise.
>
> But what is the specific scenario?
>
> Vulnerability 1 allows an attacker to change DAC protection
> on something that the attacker can then utilize via vulnerability 2,
> but MAC would prevent that?
>

You appear to be thinking in terms of files Arne and SELinux is way better
than even that. You seem to be thinking purely of stopping the compromise
in the first place (and SELinux certainly is a part of that), but if a
compromise occurs anyway, than SELinux can help to keep the compromised
code contained and isolated within a localised part of the system.

For example, SELinux restricts _which_ network ports a process can open.
If the process isn't allowed to open those ports normally, then any
hostile code running in that process is also restricted in what ports
it can open.

SELinux isn't just about files on disks, it's about protecting resources
in general and in SELinux, _each_ network port is just another resource
to be protected.

This is a _major_ improvement over what VMS can offer in terms of security.

> I could happen, but I don't see it as a common scenario.
>
> SELinux is certainly useful and relevant, but it does much
> more than SEVMS MAC.
>

Exactly. SEVMS MAC is limited compared to what SELinux can do.
For example, the last public documentation I could find showed no
integration of SEVMS into UCX, or TCP/IP in general, at all.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-11-21 13:41:04 +0000, Simon Clubley said:

> SEVMS MAC is limited compared to what SELinux can do.
> For example, the last public documentation I could find showed no
> integration of SEVMS into UCX, or TCP/IP in general, at all.

DECnet was included in the SEVMS work, but the DECnet network was also
required to be entirely private and protected.

IP was not included, and AFAIK has never acquired support any for MAC.

There was an effort to add Multi-Level Security (MLS) support into
OpenVMS and into IP, which involved changes to NFS and a whole pile of
other network chatter. Work on MLS was canceled well before it became
available. That happened around the same time work on SEVMS itself was
shelved. MLS was never integrated past a few symbols and such
incorporated into the base OS. q.v. the Access Control List Object
Information Label (ACE$C_OIL), etc.

OpenVMS is bad at isolating compromised apps. It's sorta-kinda possible
if the local folks are good at this stuff and expend some effort
messing about with ACLs on all sorts of stuff within the app, but still
comparatively limited. And it's very easy to miss something. Absent MAC
security, an app can expose its own data, or can potentially perform
various unintended-by-the-developer activities at run-time. The latter
is the sort of stuff that usuallyy gets blocked by pledge() calls, or
jails/sandboxes.

--
Pure Personal Opinion | HoffmanLabs LLC

On Mon, 2022-11-21 at 15:27 -0500, Stephen Hoffman wrote:
> OpenVMS is bad at isolating compromised apps. It's sorta-kinda
> possible if the local folks are good at this stuff and expend some
> effort messing about with ACLs on all sorts of stuff within the app,
> but still comparatively limited. And it's very easy to miss
> something. Absent MAC security, an app can expose its own data, or
> can potentially perform various unintended-by-the-developer
> activities at run-time. The latter is the sort of stuff that usuallyy
> gets blocked by pledge() calls, or jails/sandboxes.

If OpenVMS can support nested virtualisation on x86_64, I guess it
could be possible to run OpenVMS within OpenVMS, opening the
possibility to isolate applications from each other.

I can do it with Linux and VirtualBox, running Windows 11 as a guest,
with Virtualbox installed in it, running windows 10 in it as another
guest. Turtles all the way down ...
--
Tactical Nuclear Kittens

On 2022-11-21 23:58:10 +0000, Single Stage to Orbit said:

> On Mon, 2022-11-21 at 15:27 -0500, Stephen Hoffman wrote:
>> OpenVMS is bad at isolating compromised apps. It's sorta-kinda possible
>> if the local folks are good at this stuff and expend some effort
>> messing about with ACLs on all sorts of stuff within the app, but still
>> comparatively limited. And it's very easy to miss something. Absent MAC
>> security, an app can expose its own data, or can potentially perform
>> various unintended-by-the-developer activities at run-time. The latter
>> is the sort of stuff that usuallyy gets blocked by pledge() calls, or
>> jails/sandboxes.
>
> If OpenVMS can support nested virtualisation on x86_64, I guess it
> could be possible to run OpenVMS within OpenVMS, opening the
> possibility to isolate applications from each other.
>
> I can do it with Linux and VirtualBox, running Windows 11 as a guest,
> with Virtualbox installed in it, running windows 10 in it as another
> guest. Turtles all the way down ...

VSI is only supporting virtualized use at present and not native boot,
which makes nesting OpenVMS {or whatever} atop OpenVMS atop {supported
hypervisor} a somewhat less than appealing configuration.

There's no OpenVMS Hyper-VSI 😉 or BHyVSI 😉 support or similar listed
in the roadmap, and I'd expect to see native boot before the arrival of
an integrated hypervisor.

Booting a guest still doesn't isolate damage from arising within a
particular subsystem, though it does save some on hardware when
compared with the classic app-per-box design.

--
Pure Personal Opinion | HoffmanLabs LLC