First come, first trusted

[AndrewAPrice]

Hello, my OS is built around a microkernel and I want to come up with a permission system.

I'm inspired by the permission systems on a phone, where I trust the user more than I trust the programs they can install.

E.g. asking the user: "Can Snapchat access your camera?", "Can Photoshop access this file?" "Can Steam install software?"

But, being a microkernel, I want to keep this permission system outside of the kernel. The microkernally thing to do is to build a Permissions Service to act as the trusted source when anyone is wondering "Can this process perform device IO?" "Can this process access your photos?"

But, how can the operating system (the ecosystem of servers, drivers, and applications) know who to trust, to tell you who you can trust (in other words: multiple processes can say "I'm the Permissions Service" but which one is the real one?)

This problem can extend to other services. Part of the flexibility of a microkernel is that it's super flexible if you want to exchange parts around. But, if two processes say "I'm the Window Manager", who should your UI system talk to?

I don't like the idea of my microkernel being biased and favoring one Window Manager over the other if multiple processes register themselves as Window Managers. Nor do I want you to be using your computer then run what you think is a game and it registers itself as the Window Manager and streams your screen to a server.

What options do microkernel based OS's have for dealing with this?

The best option that can come to my mind is "first come, first trusted". The first service* that says it's the Permission Service, Window Manager, etc. is the one we believe. Then you just need to make sure your essential services get loaded at boot time before any applications.

This still has at least potential exploit. A process could find a way to crash a service it wants to replace first, then register itself as the new service. This doesn't close the attack, but could help a little if we had a Health Monitor service that said "Solitaire 5000 is trying to register itself as the virtual file system service, and one is already running on your computer. I think this is malicious, so I've killed the process." The Health Monitor service could have a list of services that should be singletons and trigger if another instance is trying to run.

* I load the initial set of services as multiboot modules. Something critical like the Permissions Service could be loaded via GRUB to ensure it becomes the first Permissions Service.

[xeyes]

Assume that the micro kernel is still the one that loads binary images to execute and can talk to HW.

Then the canonical way to lock things down is to store signatures in a hardware vault like the TPM.

The kernel can thus positively identify that a file being loaded is the "permission system", a file with the name of "Solitaire 5000" with the correct signature would still run as the permission system.

Of course, turtles all the way down.

Who can attest that the kernel, grub or even the TPM is trustworthy?

[Crono]

You want security and you want flexibility. Do not exist together. Other than signatures you best option is as rigid/strict api as possible.
As far as 1st come 1st trusted - erasing code that does initial setup and setups initial communications is most effective. With human user involved - it is simply considerably more code.
You cant crash a service actively running and missbehaving - you crash OS saving info about the service which you wont run on next reboot. But you are not yet ready for this?

Nothing should be loaded thru 3rd party soft. Buggy uefi is enough i think.

[AndrewAPrice]

I want my kernel not to be dependent on my greater OS, so one idea I had was to take advantage of multiboot modules. I use multiboot modules to load the initial services (e.g. I need some way to load the VFS before I my OS can load services itself off disk.)

I could load an allowlist as a multiboot module. The allowlist could be a list of processes and services they're allowed to register. The kernel would use this until we've finished loading all of the multiboot modules after which the Permissions Service would take over.

[nexos]

My plan is for the kernel to launch one process (init), and than init uses whatever policy it wants to load other services.

My system is somewhat co-located; the core of user-space (the VFS, object manager, security manager, settings manager, etc) are only going to be in one process since they interact a lot with each other. Hence init's loading logic is also pretty simple as it only needs to load one service before it has access to the whole security infrastructure. Of course drivers are all going to be in there own process so we get the security of microkernels, plus 3rd party services can be loaded as well.

[eekee]

My system is somewhat co-located; the core of user-space (the VFS, object manager, security manager, settings manager, etc) are only going to be in one process since they interact a lot with each other.

Uh... with all those in 1 process, it looks like vulnerabilities in VFS, object manager or settings manager could be used to attack the security manager.

[nexos]

My system is somewhat co-located; the core of user-space (the VFS, object manager, security manager, settings manager, etc) are only going to be in one process since they interact a lot with each other.

Uh... with all those in 1 process, it looks like vulnerabilities in VFS, object manager or settings manager could be used to attack the security manager.

I mean yes, but a lot of making a good microkernel is balancing performance and security right. It still is better than a monolithic kernel.

[Crono]

Uh... with all those in 1 proces.....

Wrong api, wrong functions inputs and returns, wrong policies, absent extra('unneeded') sanity checks.

[eekee]

My system is somewhat co-located; the core of user-space (the VFS, object manager, security manager, settings manager, etc) are only going to be in one process since they interact a lot with each other.

Uh... with all those in 1 process, it looks like vulnerabilities in VFS, object manager or settings manager could be used to attack the security manager.

I mean yes, but a lot of making a good microkernel is balancing performance and security right. It still is better than a monolithic kernel.

Well all right. I only asked because of my time with Plan 9 where the security manager (or or rather the authentication service) is intended to run on a separate computer!

Uh... with all those in 1 proces.....

Wrong api, wrong functions inputs and returns, wrong policies, absent extra('unneeded') sanity checks.

Uh, who or what are you criticizing?