STOP (see my other comments) still used all four rings for quite a long time. Shortly before I joined, they had rearchitected the kernel in a way that could achieve the same levels of security without them. My colleagues joke about having to be good at writing kernels because they needed four of them for a single system. Performance when running at/transitioning between different hardware levels was less than stellar.
The problem today, though, is that the hardware stopped supporting them. x86-64 now only has ring 0 and 1 (plus -1, -2 for virtualization and SMM, etc... but those aren't quite the same). aarch-64 has four (flipped, so 0 is user, 1 is OS, etc...) but I'm still not certain how these are actually used in practice. 3 and 4 seem similar to x86's -1, -2, but I need to study that more. So in a sense, Linux/Unix do use all four but not necessarily at an OS level and not in the multics way.
> - better permissions by default
I agree. STOP is built around this model; it doesn't even have the concept of root and I personally think it's the right way to go. But Linux does have something similar in SE Linux.
> - finer-grain memory permissions
I'm curious about what you have in mind. STOP used segments back when that's what the hardware expected, but now hardware is designed around the paging and virtual address model. I'm not sure there's a whole lot of room for the OS to experiment in this space, but happy to be proved wrong.
> - no buffer overflows (and minimal memory errors)
At some level, dealing with memory requires trusted hardware access, and it's always possible for a programmer to screw something up there. I'm a little surprised things like tagged memory and CHERI (which require hardware support) haven't taken off. Maybe it's still coming, but it seems not many know or care about it.
There's also the write-not-execute (W^X) model started by PaX linux that removes the writable attribute from memory used to store instructions. I don't remember now if that's actually used in any of the nix's. I implemented support for it in STOP, but there's a lot of software (especially JIT'd languages) out there that breaks when enabled. At the end of the day, it's a mitigation, not a "fix."
> - long command names in addition to short abbreviations (easy to implement in linux/unix, just missing)
> - multiple entry points for commands (currently faked with symlinks)
> - (related) being able to call into an executable like a library
> - unified storage model (can sort of be faked with mmap())
I'm not familiar enough with multics to understand the benefits of these. Would you consider hard links to be the same as symlinks for multiple commands? And is there a benefit to calling directly into an executable instead of making a shared library and a thin executable that uses it? Would love to hear more about what it is you want for all these.
> I'm a little surprised things like tagged memory and CHERI
I think we're seeing some improvements in memory safety for C (e.g. -fbounds-safety in clang) and C++ (e.g. -fsanitize=address) as well as adoption of more memory-safe languages (Rust, Swift, Java, Go, etc.) And I wouldn't be surprised to see Apple eventually add some hardware support for memory safety to Apple Silicon (note that Morello was a prototype implementation of CHERI for ARM.)
> And is there a benefit to calling directly into an executable instead of making a shared library and a thin executable that uses it?
I think so - having one thing instead of two, and being able to use it for either purpose with minimal effort.
Always fun to see Multics pop up; the influence it had on computing is pretty impressive and its influence lives on in many projects. As just one personally relevant example, the SCOMP mentioned in the glossary [0] and described in more detail on the history page under 5.4.1 [1] became the STOP operating system which is still in active development and is what I still work on today. (Technically, the SCOMP was the whole machine, and STOP "SCOMP Trusted Operating Program" was its operating system). Up until pretty recently, we still had a Multician working on STOP, and have a guy from the Honewell days still plugging away on it.
I've been gainfully employed for well over a decade working on it and it's been around in one form or another for over 40 years. We're constantly improving performance and capabilities, adding support for more hardware, supporting the specific needs of our customers etc... Just like any modern operating system, it's never really "complete". STOP is a "security from the ground up" OS, where security isn't just a first-order priority, it's the entire point, typically used in/as multilevel security solutions.
There's a link in my profile to the company products page for my group, which includes a link to the STOP OS page. There used to be additional documents you could download from those pages, but it looks like they're not working any more.
The short version is that it implements three different MAC (mandatory access control) policies (RBAC, Bell-LaPadula, Biba) and the standard *nix DAC policies. It's designed for safely handling/moving data on/between multiple classification levels. (See the SCOMP section in [0] for history). From a user perspective, it's very similar to Linux, with a largely Linux-like ABI and similar user interfaces, including a full X/xfce GUI environment if you want, though most actual deployments tend to run headless with only required software loaded. It runs on both small embedded boards and large enterprise servers and a bunch in between.
The data diode one reminds me of a null-modem cable I once did where I forked the TX line to a second DB-25 so that a server could eavesdrop the data coming from the PABX to the call tracking box. The server would then push it to all stations connected to a socket, where a Java applet would display the proper greeting the support agent would use when the call came in.
BAE Systems, CSP - Software Engineer - Onsite (with some work from home available) - Reston, Virginia USA
CSP, or Cyber Security Products is a small group within BAE Systems that develops a secure operating system, cross-domain network applications, and diode solutions. We are looking for several entry-level to junior developers to join our team on each of these products, and an experienced GUI dev. Must be able to get a secret clearance.
OS product - We need someone to help port and maintain packages that get shipped with our OS, but also be able to dig into the lower layers of the OS and kernel to make said packages work. Being comfortable in several languages will be useful, but a good chunk of the job will be working with C. If you enjoy working on and improving build systems, or have had any experience maintaining open source software or package repos and also have an interest in kernel development, this would be a great job for you. The more experienced you get, the more opportunities there are for kernel tasks depending on your interests. https://jobs.baesystems.com/global/en/job/74124BR/Software-D...
Cross Domain Guard - This position is for a developer to help with the development of several guard applications that filter data crossing network boundaries. A well-suited candidate would be interested in network protocols, file formats and data types, and network security. Most development is C++.
Diode - Our diode solutions are products that only pass network traffic in one direction. We are looking for some help developing the software that surrounds these products, coordinating the data that traverses the link. Apply using either link above.
Use the links above to apply, but in order to make sure your resume doesn't get lost in HR, feel free to also leave your info here or email me (address in profile). Please include "CSP Job" in the subject line to avoid the filters.
STOP (see my other comments) still used all four rings for quite a long time. Shortly before I joined, they had rearchitected the kernel in a way that could achieve the same levels of security without them. My colleagues joke about having to be good at writing kernels because they needed four of them for a single system. Performance when running at/transitioning between different hardware levels was less than stellar.
The problem today, though, is that the hardware stopped supporting them. x86-64 now only has ring 0 and 1 (plus -1, -2 for virtualization and SMM, etc... but those aren't quite the same). aarch-64 has four (flipped, so 0 is user, 1 is OS, etc...) but I'm still not certain how these are actually used in practice. 3 and 4 seem similar to x86's -1, -2, but I need to study that more. So in a sense, Linux/Unix do use all four but not necessarily at an OS level and not in the multics way.
> - better permissions by default
I agree. STOP is built around this model; it doesn't even have the concept of root and I personally think it's the right way to go. But Linux does have something similar in SE Linux.
> - finer-grain memory permissions
I'm curious about what you have in mind. STOP used segments back when that's what the hardware expected, but now hardware is designed around the paging and virtual address model. I'm not sure there's a whole lot of room for the OS to experiment in this space, but happy to be proved wrong.
> - no buffer overflows (and minimal memory errors)
At some level, dealing with memory requires trusted hardware access, and it's always possible for a programmer to screw something up there. I'm a little surprised things like tagged memory and CHERI (which require hardware support) haven't taken off. Maybe it's still coming, but it seems not many know or care about it.
There's also the write-not-execute (W^X) model started by PaX linux that removes the writable attribute from memory used to store instructions. I don't remember now if that's actually used in any of the nix's. I implemented support for it in STOP, but there's a lot of software (especially JIT'd languages) out there that breaks when enabled. At the end of the day, it's a mitigation, not a "fix."
> - long command names in addition to short abbreviations (easy to implement in linux/unix, just missing)
> - multiple entry points for commands (currently faked with symlinks)
> - (related) being able to call into an executable like a library
> - unified storage model (can sort of be faked with mmap())
I'm not familiar enough with multics to understand the benefits of these. Would you consider hard links to be the same as symlinks for multiple commands? And is there a benefit to calling directly into an executable instead of making a shared library and a thin executable that uses it? Would love to hear more about what it is you want for all these.