On Thursday, October 12, 2023 at 9:50:02 AM UTC-7, Johnny Billquist wrote:
> On 2023-10-12 17:49, Dan Cross wrote:
> > In article <ug4hod$2h6$1...@news.misty.com>,
> > Johnny Billquist <b...@softjar.se> wrote:
> >> On 2023-10-10 19:41, Simon Clubley wrote:
> >> The root privileges, and related fallout is still relevant in Unix
> >> today, even if things are better than they used to be.
> >
> > Indeed. But modern Unix's also have capability systems that can
> > obviate much of the need for root. It's possible to run complex
> > network services on low ports without resorting to being `root`,
> > for instance.
>
> Yes. Capabilities are an effort to avoid having everything run as root.
> But root still exists, and shortcircuit all the security systems.
> And getting rid of is in itself equially scary. Who knows how stuck your
> system might become if root were to go away. Everything is so basically
> dependent on root existing and being special, still.

Yep. In the days before Linux capabilities(7) and Solaris privileges(5), there wasn't a good way to bind network services to low ports without making the executable setuid root. The same for accessing raw sockets, raising a process to realtime priority, etc..

I've always thought that VMS was very innovative in having a 64-bit mask of privilege bits and providing various ways to attach them to both users and to privileged shareable images (Linux attaches caps to executables and scripts, while Solaris can also associate its privileges with user accounts).

I have very little experience with Solaris privileges (RBAC), other than knowing it has them, and that there are commands to display and edit the rights profile database, which is stored in /etc files, and to change roles. Here's a good quick guide to using RBAC:

https://linux-unix-invasion.blogspot.com/2014/09/solaris-11-configuring-rbac.html

Solaris 11 lets you completely disable root user logins and assign a "solaris.system.maintenance" authorization to admin users so that they can log in as themselves for maintenance, even in single-user mode. But UID 0 still exists, and I assume that many if not most UNIX daemons are still running as UID 0 in Solaris.

https://blogs.oracle.com/solaris/post/completely-disabling-root-logins-on-solaris-11

From an auditing standpoint, I think both OpenVMS and Solaris have a better approach than Linux, which puts its caps in extended filesystem attributes attached to the executable receiving them. On Solaris, everything's in /etc files with Solaris commands to manipulate them, and on VMS, user privileges are part of SYSUAF.DAT, while privileged shareables have to be installed on each boot so you can audit the install commands in your startup scripts to see what will persist across a reboot.

The downside of Linux and VMS is the list of caps/privs isn't perfect and could benefit from improvements. In the Linux world, there's active development in creating new caps, but then you need to have a newer Linux kernel and cap-utils to take advantage.

The overloaded catch-all Linux cap is CAP_SYS_ADMIN, and the capabilities(7) man page has a note that CAP_SYS_ADMIN is overloaded, and a further "Notes to kernel developers" explaining the goals of governing new kernel features by capabilities and warning:

* Don't choose CAP_SYS_ADMIN if you can possibly avoid it! A vast proportion of existing capability checks are associated with this capability (see the partial list above). It can plausibly be called "the new root", since on the one hand, it confers a wide range of powers, and on the other hand, its broad scope means that this is the capability that is required by many privileged programs. Don't make the problem worse. The only new features that should be associated with CAP_SYS_ADMIN are ones that closely match existing uses in that silo.

I think the VMS privilege bits haven't been changed in decades. I looked up what privilege you need to bind to a low TCP/IP port:

"The process must have SYSPRV, BYPASS, or OPER privilege to bind port numbers 1 to 1023."

It looks like SYSPRV is the closest equivalent to UID 0, and then the DEC TCP/IP developers added two additional vaguely related privileges with fewer powers so developers would have a choice. Linux has a CAP_NET_BIND_SERVICE to enable this one specific privilege, which is ideally the way to go. There are enough free bits in the VMS privilege mask that I think it'd be possible and desirable to take advantage of them in future versions of the OS.

Regards,
Jake Hamby

On 2023-10-12, Johnny Billquist <bqt@softjar.se> wrote:
> On 2023-10-12 17:49, Dan Cross wrote:
>> In article <ug4hod$2h6$1@news.misty.com>,
>> Johnny Billquist <bqt@softjar.se> wrote:
>>> On 2023-10-10 19:41, Simon Clubley wrote:
>>>> Likewise, if the various modes had been used properly, you could have had
>>>> a version of VMS with chunks of it properly isolated from each other.
>>>
>>> I don't think the processor modes is really usable for that isloation of
>>> thing in the first place, so I think it's a false comparison.
>>> Don't try to get things used for something they are not meant for, or
>>> fit for...
>>
>> I got the impression that's roughly what Simon was saying. The
>> architectural privilege levels on the VAX weren't as useful as
>> initially thought.
>
> I got the impression that he was complaining that VMS did not make use
> of the modes in a "good enough" way from a security point of view.
>

You are both correct.

Johnny is right in that I am saying the VMS usage of these extra modes
is horrible and doesn't really add anything from a security point of
view.

Dan is right in that I am saying that even if VMS had used these extra
modes properly for isolation purposes, the design would still not be as
good or as flexible as a purely software microkernel design.

I don't recall seeing anything post-VAX that attempts to do in hardware
what VAX did. All the current high-integrity stuff seems to be based on
microkernel designs (for example, the work done on seL4).

The closest I see anyone doing anything in hardware is the LPAR stuff
that z/Architecture implements, and I see that as isolation _between_
systems instead of the isolation _within_ a system that microkernel
designs provide.

Simon.

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

On Thursday, October 12, 2023 at 11:28:33 AM UTC-7, Simon Clubley wrote:
>
> I don't recall seeing anything post-VAX that attempts to do in hardware
> what VAX did. All the current high-integrity stuff seems to be based on
> microkernel designs (for example, the work done on seL4).
>
> The closest I see anyone doing anything in hardware is the LPAR stuff
> that z/Architecture implements, and I see that as isolation _between_
> systems instead of the isolation _within_ a system that microkernel
> designs provide.

z/OS leverages one unique feature of S/390 that I believe predates VAX, storage protect keys:

https://www.ibm.com/docs/en/zos-basic-skills?topic=storage-what-is-protection

https://www.ibm.com/docs/en/zos/3.1.0?topic=authorization-selecting-storage-key

In addition to paged virtual memory, there's an additional storage key check. Each 4K memory page can have a key from 0 to 15, and programs have to have a matching storage key, or key 0, to access the page. User code runs in key 8, and uses MMU page mappings to protect user address spaces from other users (like UNIX/VMS/Windows).

I believe this feature gets disabled on any CPU cores that users license from IBM to run Linux (which costs less than a fully-functional CPU core) because Linux doesn't have any idea what to do with storage protect keys anyway ("storage" always refers to RAM in z/OS, while "DASD" is used for on-disk storage) and it stops IBM OSs from running.

The concept seems similar to VAX's 4 rings in terms of protecting access to shared memory regions. Shared memory between code running in different privilege rings appears to be a weak spot for VMS privilege escalation vulnerabilities, based on the ones that have been discovered.

Mainframes can be extremely secure when properly configured, but the permission model (and everything else about z/OS) is so strange that if you aren't an expert, you could easily write vulnerable code or misconfigure the system if you don't understand how everything fits together.

The difference between the two approaches seems to be that with z/OS, the sysadmin and the OS internally can allocate one of 16 keys required to access each 4K page, while VAX/VMS has four sets of permission bits for each page, one for each mode. Either way, it's an extra layer of security limiting who can access a memory region on a per-process basis.

Regards,
Jake Hamby

On 10/12/2023 2:28 PM, Simon Clubley wrote:
> The closest I see anyone doing anything in hardware is the LPAR stuff
> that z/Architecture implements, and I see that as isolation _between_
> systems instead of the isolation _within_ a system that microkernel
> designs provide.

Totally different thing.

The equivalent from the VMS world to LPAR must be Galaxy (even though
I suspect there are differences).

Arne

On 10/12/2023 2:28 PM, Simon Clubley wrote:
> I don't recall seeing anything post-VAX that attempts to do in hardware
> what VAX did. All the current high-integrity stuff seems to be based on
> microkernel designs (for example, the work done on seL4).

Moderns CPU's has become crazy fast but are also pretty
boring/uniform in design.

Even though if understand it correct then x86 did have 4 modes
and it was first with x86-64 they went for 2 modes.

Arne

On Thursday, October 12, 2023 at 12:28:15 PM UTC-7, Jake Hamby (Solid State Jake) wrote:

(snip)

> z/OS leverages one unique feature of S/390 that I believe predates VAX, storage protect keys:

> https://www.ibm.com/docs/en/zos-basic-skills?topic=storage-what-is-protection
> https://www.ibm.com/docs/en/zos/3.1.0?topic=authorization-selecting-storage-key

Protect keys go back to S/360 and OS/360. Well, they were optional on the lower
models of S/360.

OS/360 runs in a single real address space. Storage keys are the only protection
against reading or writing someone else's memory space.

OS/360 MVT could have at most 15 different user programs running at once.
Mostly with memory sizes, that wasn't much of a problem.

For S/360, and much of S/370 years, keys are on 2K blocks.

Sometime later, the "4K key feature(sic)" was added.

By the way, the first use of IC memory in a commercially available
computer is the key storage on the 360/91. 16 bit SRAM chips.

> In addition to paged virtual memory, there's an additional storage key check.
> Each 4K memory page can have a key from 0 to 15, and programs have to have a
> matching storage key, or key 0, to access the page. User code runs in key 8, and uses
> MMU page mappings to protect user address spaces from other users
> (like UNIX/VMS/Windows).

Virtual storage and page (and segment) protection allow the system
to block access other than protection keys. So, yes, at least for the OS
that I know, key 8 is used for usual user jobs. Other keys for other parts
of the system.

OS/VS2 1.x (SVS) was based on MVT, which ran user jobs in one big
virtual address space. I suspect for that, the keys were still used.

With MVS, user jobs had their own address space, though all of the OS
is still addressable. Much of the system depends on users executing
things like access methods in system space, but user readable.

> I believe this feature gets disabled on any CPU cores that users license from IBM to run Linux (which costs less than a fully-functional CPU core) because Linux doesn't have any idea what to do with storage protect keys anyway ("storage" always refers to RAM in z/OS, while "DASD" is used for on-disk storage) and it stops IBM OSs from running.

Interesting way to do it.

> The concept seems similar to VAX's 4 rings in terms of protecting access to shared memory regions. Shared memory between code running in different privilege rings appears to be a weak spot for VMS privilege escalation vulnerabilities, based on the ones that have been discovered.

(snip)

In article <ug9dsd$2l4dl$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-10-12, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-10-12 17:49, Dan Cross wrote:
>>> In article <ug4hod$2h6$1@news.misty.com>,
>>> Johnny Billquist <bqt@softjar.se> wrote:
>>>> On 2023-10-10 19:41, Simon Clubley wrote:
>>>>> Likewise, if the various modes had been used properly, you could have had
>>>>> a version of VMS with chunks of it properly isolated from each other.
>>>>
>>>> I don't think the processor modes is really usable for that isloation of
>>>> thing in the first place, so I think it's a false comparison.
>>>> Don't try to get things used for something they are not meant for, or
>>>> fit for...
>>>
>>> I got the impression that's roughly what Simon was saying. The
>>> architectural privilege levels on the VAX weren't as useful as
>>> initially thought.
>>
>> I got the impression that he was complaining that VMS did not make use
>> of the modes in a "good enough" way from a security point of view.
>
>You are both correct.
>
>Johnny is right in that I am saying the VMS usage of these extra modes
>is horrible and doesn't really add anything from a security point of
>view.
>
>Dan is right in that I am saying that even if VMS had used these extra
>modes properly for isolation purposes, the design would still not be as
>good or as flexible as a purely software microkernel design.

Ok, good to understand.

>I don't recall seeing anything post-VAX that attempts to do in hardware
>what VAX did. All the current high-integrity stuff seems to be based on
>microkernel designs (for example, the work done on seL4).
>
>The closest I see anyone doing anything in hardware is the LPAR stuff
>that z/Architecture implements, and I see that as isolation _between_
>systems instead of the isolation _within_ a system that microkernel
>designs provide.

I see a lot of work being done with virtualization that amounts
to essentially an extra ring; even RISC-V has 3 modes. Perhaps
that is actually what is desired, though; a different ring of
protection, but one that actually means something.

- Dan C.

In article <ug9i6c$2lvsn$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 10/12/2023 2:28 PM, Simon Clubley wrote:
>> I don't recall seeing anything post-VAX that attempts to do in hardware
>> what VAX did. All the current high-integrity stuff seems to be based on
>> microkernel designs (for example, the work done on seL4).
>
>Moderns CPU's has become crazy fast but are also pretty
>boring/uniform in design.
>
>Even though if understand it correct then x86 did have 4 modes
>and it was first with x86-64 they went for 2 modes.

x86_64 still has 4 rings; two of them just aren't meaningfully
useful. Come to think of it, that was mostly true of x86, as
well.

- Dan C.

On Thursday, October 12, 2023 at 1:18:11 PM UTC-7, Dan Cross wrote:
>
> I see a lot of work being done with virtualization that amounts
> to essentially an extra ring; even RISC-V has 3 modes. Perhaps
> that is actually what is desired, though; a different ring of
> protection, but one that actually means something.

I know AArch64 has an extra "secure" ring above the hypervisor ring:

EL0 = apps
EL1 = guest OS
EL2 = hypervisor
EL3 = secure monitor/firmware

I also know that POWER9 added a very similar feature called "ultravisor" mode.

https://docs.kernel.org/powerpc/ultravisor.html

Regards,
Jake Hamby

On Thursday, October 12, 2023 at 1:21:17 PM UTC-7, Dan Cross wrote:

(snip)

> x86_64 still has 4 rings; two of them just aren't meaningfully
> useful. Come to think of it, that was mostly true of x86, as
> well.
I remember that OS/2 used ring 2 to allow some programs the
ability to do I/O directly to I/O devices. I don't remember now
how much control over which I/O devices it had.

On 2023-10-12, Jake Hamby (Solid State Jake) <jake.hamby@gmail.com> wrote:
> On Thursday, October 12, 2023 at 1:18:11?PM UTC-7, Dan Cross wrote:
>>
>> I see a lot of work being done with virtualization that amounts
>> to essentially an extra ring; even RISC-V has 3 modes. Perhaps
>> that is actually what is desired, though; a different ring of
>> protection, but one that actually means something.
>
> I know AArch64 has an extra "secure" ring above the hypervisor ring:
>
> EL0 = apps
> EL1 = guest OS
> EL2 = hypervisor
> EL3 = secure monitor/firmware
>
> I also know that POWER9 added a very similar feature called "ultravisor" mode.
>
> https://docs.kernel.org/powerpc/ultravisor.html
>

However these do nothing to help with isolation of functionality _within_
an OS instance, only with isolation _between_ OS instances.

Simon.

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

In article <7b196588-cd3b-4ee3-812c-27227c7df15dn@googlegroups.com>,
gah4 <gah4@u.washington.edu> wrote:
>On Thursday, October 12, 2023 at 1:21:17 PM UTC-7, Dan Cross wrote:
>
>(snip)
>
>> x86_64 still has 4 rings; two of them just aren't meaningfully
>> useful. Come to think of it, that was mostly true of x86, as
>> well.
>
>I remember that OS/2 used ring 2 to allow some programs the
>ability to do I/O directly to I/O devices. I don't remember now
>how much control over which I/O devices it had.

Yeah. OS/2 2.x was about the only consumer of the ring
mechanism that I'm aware of. By the time the 386 came out with
paging, it was basically useless (pages have a U/S bit, not a
pair and segmentation was falling out of favor).

- Dan C.

In article <ugbdjh$364ml$2@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-10-12, Jake Hamby (Solid State Jake) <jake.hamby@gmail.com> wrote:
>> On Thursday, October 12, 2023 at 1:18:11?PM UTC-7, Dan Cross wrote:
>>>
>>> I see a lot of work being done with virtualization that amounts
>>> to essentially an extra ring; even RISC-V has 3 modes. Perhaps
>>> that is actually what is desired, though; a different ring of
>>> protection, but one that actually means something.
>>
>> I know AArch64 has an extra "secure" ring above the hypervisor ring:
>>
>> EL0 = apps
>> EL1 = guest OS
>> EL2 = hypervisor
>> EL3 = secure monitor/firmware
>>
>> I also know that POWER9 added a very similar feature called "ultravisor" mode.
>>
>> https://docs.kernel.org/powerpc/ultravisor.html
>
>However these do nothing to help with isolation of functionality _within_
>an OS instance, only with isolation _between_ OS instances.

Not quite true; there's been interesting research in running
things like device drivers in very lightweight VMs within the
overall context of a traditional kernel to provide a security
boundary based on microkernel-like principles. E.g.,
https://www.usenix.org/conference/atc19/presentation/narayanan

On a research project a few years ago, I proposed that we run
the ACPICA AML interpreter in a lightweight VM to isolate it
from the rest of the kernel; a colleague took the idea and
made it run in userspace which was functionally equivalent.
Basically, an ACPI event translated to a change to a file
descriptor, and a thread in a process was blocked on reading
from that FD: thus, we reflected the event into userspace for
handling; we ran the flow, and wrote the results back into the
kernel.

The ring architecture for isolating components of a vertically
layered OS (instead of horizontally disjoint, as in a ukernel)
get reinvented over and over again.

- Dan C.

On 2023-10-13, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>
> Not quite true; there's been interesting research in running
> things like device drivers in very lightweight VMs within the
> overall context of a traditional kernel to provide a security
> boundary based on microkernel-like principles. E.g.,
> https://www.usenix.org/conference/atc19/presentation/narayanan
>

Thank you. I was not aware of that work.

Simon.

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