OSDev.org

The Place to Start for Operating System Developers
It is currently Sat Dec 03, 2022 7:32 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: First come, first trusted
PostPosted: Sat Aug 20, 2022 8:38 pm 
Offline
Member
Member
User avatar

Joined: Mon Jun 05, 2006 11:00 pm
Posts: 2258
Location: USA (and Australia)
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.

_________________
My OS is Perception.


Top
 Profile  
 
 Post subject: Re: First come, first trusted
PostPosted: Sat Aug 20, 2022 9:11 pm 
Offline
Member
Member

Joined: Mon Dec 07, 2020 8:09 am
Posts: 212
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?


Top
 Profile  
 
 Post subject: Re: First come, first trusted
PostPosted: Sat Oct 01, 2022 2:02 pm 
Offline

Joined: Tue Jul 19, 2022 2:49 pm
Posts: 10
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.


Top
 Profile  
 
 Post subject: Re: First come, first trusted
PostPosted: Sun Oct 02, 2022 2:25 pm 
Offline
Member
Member
User avatar

Joined: Mon Jun 05, 2006 11:00 pm
Posts: 2258
Location: USA (and Australia)
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.

_________________
My OS is Perception.


Top
 Profile  
 
 Post subject: Re: First come, first trusted
PostPosted: Sun Oct 02, 2022 3:54 pm 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1045
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.

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Top
 Profile  
 
 Post subject: Re: First come, first trusted
PostPosted: Wed Oct 12, 2022 8:48 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 690
Location: Oscillating between two different potentials
nexos wrote:
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.

_________________
[Kaph — A set of system ideals] [Pichiciego — A slightly quirky bootable Forth]
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: First come, first trusted
PostPosted: Thu Oct 13, 2022 2:06 pm 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1045
eekee wrote:
nexos wrote:
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.

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Top
 Profile  
 
 Post subject: Re: First come, first trusted
PostPosted: Sat Oct 15, 2022 2:32 pm 
Offline

Joined: Tue Jul 19, 2022 2:49 pm
Posts: 10
eekee wrote:
Uh... with all those in 1 proces.....

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


Top
 Profile  
 
 Post subject: Re: First come, first trusted
PostPosted: Mon Oct 24, 2022 7:25 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 690
Location: Oscillating between two different potentials
nexos wrote:
eekee wrote:
nexos wrote:
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! :)



Crono wrote:
eekee wrote:
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?

_________________
[Kaph — A set of system ideals] [Pichiciego — A slightly quirky bootable Forth]
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group