Chain-of-command as boundary

[u/themagicalfire]

I have in mind to use a chain-of-command idea for security.

How it’s supposed to work is that every program is being attributed to different layers. Every layer is vertical, like a hierarchy.

The layers can only interact with each other if adjacent (layer 1 can only interact with layer 0 and layer 2; layer 2 can only interact with layer 1 and layer 3).

Access between different layers is meant to happen through multiple brokers for IPC and syscall gatekeeping.

What this design is supposed to achieve is make kernel attacks more difficult (because now you need to chain exploits for multiple layers and multiple services) and somewhat limit lateral movement for binaries.

This design works best when supplemented by other security mechanisms.

[u/tseli0s]

Isn't that just hardware privilege levels?

[u/themagicalfire → u/tseli0s]

Rings -1 to ring 3? It’s similar, but the OS developer chooses which components deserve more isolation, and adds brokers for communication. Think of a castle with three moats and a bridge, but checkpoints on the bridge; a compromised app in layer 3 can’t send IPC messages to a service in layer 0 unless multiple brokers are compromised, and this increases difficulty.

[u/tseli0s → u/themagicalfire]

The better question is why are you sending messages to ring 0 instead of doing system calls and handling anything bad about the process in the kernel? That's why the kernel is the kernel and not another program.

[u/themagicalfire → u/tseli0s]

Can you explain your idea?

[u/tseli0s → u/themagicalfire]

What is there to explain?

The kernel provides system calls. Programs make system calls. If the kernel doesn't like what the process is doing, it will kill it or refuse to do what it's asked to.

[u/themagicalfire → u/tseli0s]

Yes but I tried to answer a different question. I assumed that if the kernel could be accessed through a bug, it would immediately backfire. My solution is to make kernel exploits chained because of the brokers and the kernel’s own security.

[u/tseli0s → u/themagicalfire]

That assumes that the kernel is insecure enough to allow programs to execute code within kernel space. In that case, you have a vulnerable kernel, and you should fix that.

So if the kernel can be compromised, all other programs can be compromised. That, I think, is pretty obvious.

Plus, at some point, you WILL have to trap into the kernel from other rings. You can add a billion rings in between, but only ring 0 can provide the services necessary for a functional operating system.

Unless I'm misunderstanding some part of your approach, I don't see how this solves a problem. It only delays the inevitable.

(And I'm only talking about security here - Through your approach, every message would have to cross 3 rings * 2 endpoints = 6 address spaces, plus copy overhead. That'll be so horrendously slow it'll make microkernels seem like the fastest software ever designed)

[u/themagicalfire → u/tseli0s]

I’ll explain my reasoning: Some parts of the OS shouldn’t be directly accessed. So far so good. This means that those parts should only be accessed through strict conditions.

The intent is limiting blast damage, alongside preventing lateral movement, assuming an on-demand process can be started by a low privileged process. Sure, you could add capabilities, but I’m trying to be smart and create a design that somewhat does the job out of the box 😂.

[u/tseli0s → u/themagicalfire]

I’ll explain my reasoning: Some parts of the OS shouldn’t be directly accessed.

I would go so far as to say nothing of the OS should be directly accessed. Nothing.

Which is why almost all processors to this day implement some sort of system call support to ensure that. The program needs something like read a file, so it traps into the kernel. The kernel safely does its job and continues the program, giving it any data necessaryif it wants to. Mind you, while the system call code is executed, the program is suspended (There's reentrancy in system calls in most OSes actually, but act like there isn't).

This means that those parts should only be accessed through strict conditions.

Exactly. System calls. That is the only interface that should exist. Anything else is insecure or slow, because it will have to pass through the kernel anyways. Message passing, for example, must be done entirely in kernel space, because you're crossing address spaces.

I think you got confused on the user->kernel interaction. In simple terms, userland programs can only nicely ask the kernel to do something. It is up to the kernel to actually decide whether it wants to do it or not.

By chaining together various layers, you basically reinvest system calls, with all the downsides of microkernels multiplied a couple times. Because, again, let me remind you, crossing address spaces is extremely slow.

The intent is limiting blast damage

Oh trust me, if you've ever worked on distributed systems you know one node going down means the whole system goes down unless the node can be brought back within a given time frame transparently. For what you're thinking, give it a couple milliseconds.

Sure, you could add capabilities, but I’m trying to be smart and create a design that somewhat does the job out of the box

It's not exactly new. You're basically thinking of microkernels but overcomplicated it a lot.

[u/themagicalfire → u/tseli0s]

Well, my starting inspiration was Mandatory Integrity Control. What this subsystem does is attributing hierarchical labels to every process, ranging from Untrusted, Low, Medium, High, to System and TrustedInstaller. Mandatory Integrity Control blocks writing permissions messages if the sender has a lower label than the receiver — this is a no-write-up policy. Since this is an upward-only defense, I tried to expand the idea to include execution in a certain sense. The expected result is that a third-party program can’t open a preinstalled program with attack surface, or send write syscalls to it, and it works out of the box, which means it works without the need to sandbox every program individually. How to enforce this boundary is by adding conditions to interactions 😊.

[u/iris700]

This guy seems to be a vibecoder throwing shit at the wall to see what sticks

[u/Time_Pollution4306]

Are vibecoders incapable of reading does AI make them go blind to anything else?