Implementing users in a microkernel

[NickJohnson]

I've finalized my VFS, but it has no permission system. I need a way of implementing at least the concept of users, but I don't know where to put it, because I have a microkernel. Should users be managed by the kernel? A centralized daemon? What is the best way of controlling user switching? What is a secure way of expressing the user privilege of a request, when that request may be redirected through multiple driver processes? I'm just wondering what people here usually do, because a lot of these concerns do not apply to traditional monolithic systems, so I can't find much about it.

[Hangin10]

I plan on allowing root processes (ie drivers) to set the uid (etc) of processes they create as well as get said numbers from any arbitrary pid. The kernel knows nothing of uids, except that it'll only allow access to driver syscalls from uid zero processes. Which probably means I'll need a standard location for a user info file or yet another server program.

[gerryg400]

I thought about three things when I decided.

1) what the kernel needs
2) how difficult the information is to maintain
3) ease of implementing the security you need

In my case the kernel does occasionally need to know the uid, euid etc. of process that is making a kernel call. The maintenance of the ids of a process is relatively simple and having it all in one place helps security. I keep all the ids in the process table in the kernel and provide get/set kernel calls to access them. The posix functions like getuid() etc. are simple to implement.

I don't have groups yet and haven't really thought about how I will handle multiple groups.

[cxzuk]

you have to think about who trusts who. A driver is a trusted process because a user selects it to manage a resource. As long as the kernel can verify a driver is the one it really wants to load (a checksum). So you only need to manage security from communication between processes. Which should be easy to manage as it all goes through the kernel

[Combuster]

And as far as security goes, users are stupid by definition.

[OSwhatever]

What you can have is a "process manager" like in QNX. Everything goes through that manager. If you want create a process you have to call that manager. The create process call among other kernel calls are restricted to the process manager only. The process manager exposes interfaces which enables other processes to ask what kind of security rights a particular process id has. Make sure you cannot forge caller ids in the system.

[cxzuk]

And as far as security goes, users are stupid by definition.

Yes, very good point, "users" are too vague. user's should be a grouping of a finer-grain security system like keys.

User in my previous post actually meant the human that set up the kernel and its rules to follow (installation i guess?) rather than the actual running of the system

What you can have is a "process manager" like in QNX. Everything goes through that manager. If you want create a process you have to call that manager. The create process call among other kernel calls are restricted to the process manager only. The process manager exposes interfaces which enables other processes to ask what kind of security rights a particular process id has. Make sure you cannot forge caller ids in the system.

hmm.. Im actually at this point in the design of my OS, and while i don't know what the right thing is to do, I personally feel "Security" is a feature, rather than a service. And security is really only needed at IPC (and so is an extension of it).

[rdos]

I prefer not to have users or privileges at all. After all, software applications needing access restrictions, can implement this themselves.

[Solar]

Uh-huh... so you need to implement users and permissions for virtually every program on your machine. Over and over and over again.

Or you tell your users that every other user on the system can read, edit, and / or delete their data, and that they should cope with it.

[Zacariaz]

Uh-huh... so you need to implement users and permissions for virtually every program on your machine. Over and over and over again.

Or you tell your users that every other user on the system can read, edit, and / or delete their data, and that they should cope with it.

I'll have to agree with Solars... I'm not really sure what it is... Sarcasm?

[Solar]

Two parts confusion, two parts disbelief, one part acidic sarcasm.

[OSwhatever]

Microkernels are very server oriented, with the servers running in user space. That means that many servers must implement security checks. Obviously, file system servers for example has to do this.

In the case of the file system, the difference is that it is moved from kernel space to user space for a microkernel. No big deal really, however the in kernel space all the security information was easily obtained. With servers in user space you have to find ways to transfer security information in a secure and convenient way.

See how it is implemented in a classical monolithic kernel. Probably you have in kernel system calls in order to obtain security information. Now you have to do the same in user space. Linux even enables you to install file system modules running in user space. How does Linux transfer security information to user space file systems?

[gerryg400]

Microkernels are very server oriented, with the servers running in user space. That means that many servers must implement security checks. Obviously, file system servers for example has to do this.

True, the servers need to do security checks. They will check that the client has rights to access their resources. But the kernel can be responsible for tracking the uid, gid etc. of each client. This means that a server can implement the security policy it wishes but that kernel controls the identity of each client.

[NickJohnson]

Microkernels are very server oriented, with the servers running in user space. That means that many servers must implement security checks. Obviously, file system servers for example has to do this.

True, the servers need to do security checks. They will check that the client has rights to access their resources. But the kernel can be responsible for tracking the uid, gid etc. of each client. This means that a server can implement the security policy it wishes but that kernel controls the identity of each client.

That's exactly how I ended up doing it. A couple of extra lines to hold the uid and gid of a process are not going to wreck the "purity" of a microkernel.

[rdos]

Uh-huh... so you need to implement users and permissions for virtually every program on your machine. Over and over and over again.

Or you tell your users that every other user on the system can read, edit, and / or delete their data, and that they should cope with it.

Uhm. Actually no. I do not implement security with userids and passwords. Instead, security is implemented in our credit-card application by having a static image file with a CRC, having CRCs for every driver and confguration in the image file, having no way to log onto the system, having no way to even connect to the system, having no way to load additional servers or processes, having no way to change critical configuration, having no GUI-interface and having no command-line interpreter. All communication, either for upgrading or exhanging data, is done at the initiaitive of our terminal, which makes it 100% secure. The configuration is kept at a central server, and when the system boots it first does a consistency check. Userids and passwords can never compete with this. We also save sensitive data outside of the filesystem, so it is unreadble even if the flash-disk is removed and inserted into a standard PC with an unsecure OS like Windows or Linux. It was a breeze to get this solution accepted to one of the highest security standards in the world, and it is a real pain to get any Windows or Linux based solution accepted to this level of security mostly because of open server-ports, userids/passwords that get spread, critical data stored in the filesystem or SQL-database and similar.

So, no, I have not yet implemented any application that uses userids or passwords, and I'm not likely to do it either.

Besides, it is very simple to break existing security measures for filesystems. All that is required is to boot RDOS from a floppy, and every supported fillesystem can be read on the PC, regardless of which userids and passwords have been selected.