An Idea for a two part OS I had a while ago

[EzArIk]

A while ago I was thinking about Operating Systems and I thought of something that I found quite interesting, and I was just wondering if it is feasible, and has any real merit
(at this moment I couldn't make it anyway, due to lack of experience with OS programming, but I might try one day),
basically (for lack of a better description) there would be two small Operating systems running at the same time, a MASTER and a SLAVE,
the MASTER-OS would be non networked (and in-accessible except by someone who is actually physically at the computer) it would make the final decisions about whether or not something was allowed to happen, it's area on the hard disk (or other storage medium) would be inaccessible to the SLAVE-OS,
the SLAVE-OS would be the main part the user normally interacts with, where programs where run, internet was surfed, etc.
Both OS's would display something on the screen, The MASTER-OS would display a thin strip to one side of the screen containing advanced settings which I won't go into now, while the SLAVE-OS has the basic user interface with, GUI, console, networking, etc.
if for example a program tried to run, a request would be sent by the SLAVE-OS to the MASTER-OS if the master had, for example a blocked program list with that program on it, that program couldn't run, there would be no way for a program on the SLAVE-OS to override any decision made by the MASTER-OS, which could also block or allow other things such as I.P. / remote connections, file access, etc.
One of the Ideas behind it was that even if someone managed to hack in remotely somehow, they couldn't actually interfere with any major settings and if detected could simply be blocked by the user via the MASTER-OS, the same goes for malicious programs, etc.
I will include a mock-up image of the OS on-screen display bellow. So in your opinion is it a worth while idea or not? (Sorry if I haven't described it that clearly, edit: things that look odd in the picture or that don't relate to what I've already talked about, are probably related to other ideas I had for the OS at some time, like multiple desktops(the 0/4 thing and up down buttons in the bottom corner and application window corner), pause button for running programs to be used in an emergency if you needed to free CPU without exiting a program)

[Ycep]

Learn before posting.
Basically, you have just described CPU Rings and Admin(root) user.
And yes, there is still security hole in it.

[Octacone]

Learn before posting.
Basically, you have just described CPU Rings and Admin(root) user.
And yes, there is still security hole in it.

Nope, he was not talking about that. I have never heard about those rings... There are: ring 0 (master access, kernel), ring 1/2 (hardware abstraction, e.g. Cosmos has that), ring 3 (user space).
There are security holes for sure, Window is the best example.

Now on topic: basically you are talking about 1 operating system, not two of them. A two part OS would require some engineering. For example you would have to decided specifically what would go where... What libs one part can use what other can't etc... It is not an easy task, you would really have to protect your part 1 from being accessed by third party objects. Also there are some universal ideas too, it is impossible for the OS not to use system hardware when needed. You can't just block programs from accessing certain hardware. Also you should add some sort of a memory protection protocols, so your ring "x" programs couldn't access files inside your RAM.

[EzArIk]

Now on topic: basically you are talking about 1 operating system, not two of them. A two part OS would require some engineering. For example you would have to decided specifically what would go where... What libs one part can use what other can't etc... It is not an easy task, you would really have to protect your part 1 from being accessed by third party objects. Also there are some universal ideas too, it is impossible for the OS not to use system hardware when needed. You can't just block programs from accessing certain hardware. Also you should add some sort of a memory protection protocols, so your ring "x" programs couldn't access files inside your RAM.

thanks octacone, I'm grateful for your information, so a single unified OS would be much better and easier than trying to separate things out the way I had originally intended.

[onlyonemac]

A better option would be to do it on a per-application level. It's called fencing/sandboxing. Think of Android, where apps have to request specific permissions from the user, or Firefox where the user is alerted if webpages try to do something that the user might not want (and the user can either allow or deny the action). It's basically like that, but at the OS level, where every application is run in a controlled environment and has no access to anything outside of the controlled environment unless explicitly allowed by the kernel (and ultimately the user, who tells the kernel what access to give). So if, for example, an application tries to read a file from disk, the kernel would intercept the application's request to read the file (since, after all, the application doesn't have permission to read from disk directly and the request has to go through the kernel anyway) and the user would be shown an alert asking "Do you want to allow this application to read this file?" and the user can either "allow" or "deny" (or maybe "always allow this application read files" if they trust the application). Essentially the kernel confirms all operations with the user, and the user can tell the kernel what they're OK with.

[SpyderTL]

There are already several ways to do what you are describing, today. The most obvious would be virtual machines, like VirtualBox, VMWare, V-Sphere and Hyper-V. The "host" operating system creates a virtual machine, which runs the "guest" operating system, which only has access to virtual hardware, so it is "virtually" impossible for the guest OS to impact the host OS.

After that, there are several "levels" of virtualization that you can implement. You can have a virtual kernel, where any kernel methods called by the application are virtualized so that they can not impact the actual Kernel or any other application. Then you have virtual hardware and virtual memory, which virtually all operating systems use to hide the real physical hardware and memory from the application, so that the application can not impact the rest of the system.

The virtual machine approach is probably the "safest" from a security standpoint, but there are probably still "technically" ways to get around this security layer. A 100% safe operating system is like a 100% bug-free operating system. We haven't quite gotten there, yet...

[simeonz]

Well, this is perfect thread to interject and mention an MS technology.

Windows 10 introduces VSM, security infrastructure stuck in a VM. It utilizes UEFI secure boot, IOMMU and hardware TPM (if available). The security kernel has architectural features of a micro-kernel. For example, it controls the page table modifications, but does not perform memory management decisions. They are performed by the ordinary kernel. OSes are motivated to shift to micro-kernel architecture, so this may be the beginning for MS. But in all honesty, VSM will be used by Microsoft for DRM, vTPM, etc. No matter what the officially declared intention might be. And the big clutch - SKM only installs modules directly signed by Microsoft. There is no "testing mode" or client override for this.

edit: My point is that the idea of the OP (minus the UI part) has seen some appreciation. And as SpyderTL remarked, virtualization is the natural environment for providing additional security layers (with or without OS support.)

[EzArIk]

thank you for the additional comments, I had at one point considered a virtualisation method as an option, though with my current experience at OS programming being very limited I had suspected it would be far more difficult to create a virtualisation based system, but I haven't really looked into it yet, I did a bit of investigation into sand box related stuff a while ago, but at the time was too busy with university work to really spend to much time looking in to it though,

Well, this is perfect thread to interject and mention an MS technology.
Windows 10 introduces VSM, security infrastructure stuck in a VM. It utilizes UEFI secure boot, IOMMU and hardware TPM (if available). The security kernel has architectural features of a micro-kernel. For example, it controls the page table modifications, but does not perform memory management decisions. They are performed by the ordinary kernel. ...
edit: My point is that the idea of the OP (minus the UI part) has seen some appreciation. And as SpyderTL remarked, virtualization is the natural environment for providing additional security layers (with or without OS support.)

it's interesting to see that Microsoft seems to have done something along the same lines as what I mentioned,
thank you SpyderTL (and everyone else) I will definitely have a much deeper look into visualisation, it seems like a very promising option.

[Schol-R-LEA]

As has already been mentioned, what you seem to be looking for is some sort of virtualizer; my recommendation is that you look into the concept of 'containerized hypervisors', which are specifically based on the idea of running applications (typically network servers) in sandboxed virtual operating systems. Like with the related exokernel architecture (which uses virtualization, but reverses the abstraction process - instead of adding abstractions, it strips them away), containerized hypervisors tends to work best where the applications have little or no IPC, and work with a limited subset of the hardware (which makes it possible to cache a lot of the accesses efficiently).

You might want to look at the Synthesis kernel, which treats each user process as a virtual 's-machine' (though it doesn't use hardware virtualization of the kind we are talking about, not exactly anyway), but uses a number of advanced techniques to reduce the overhead regarding system calls, driver invocation, IPC, and so forth. It is probably out of your current skill level to fully understand it - I am not sure it is within mine, TBH - but you might find reviewing the ideas briefly to be insightful, or at least help you frame your own ideas more clearly.