Well, so you are not talking about a general-purpose, multi-user operating system, but a single-user embedded solution. Since you only have one user who can interface with the system only in a very specific way, you don't have to bother about multi-user security.
That's quite a different scenario from what the rest are talking about here.
Implementing users in a microkernel
Re: Implementing users in a microkernel
Every good solution is obvious once you've found it.
Re: Implementing users in a microkernel
I wouldn't call it a single user system. There are many users (customers that fill up their cars), but each user can only interface with a payment application, and do not log in or have access to files, applications or similar. It would be more correct to say that there are no users at all in the ordinary sense of the word, because nobody could actually do anything that users typically do in multiuser systems, not even the company that owns the system. They instead handle their local card data on the web (with userids and passwords).
When RDOS is run in a more ordinary context, it is more similar to DOS than to multiuser systems. That is a design choice. No sense in cluttering the system with access and / or security stuff when it is intended for embeded systems, and in fact can target markets where multiuser systems have problems to uphold strong security requirements because they rely too much on authentication with userids/passwords.
When RDOS is run in a more ordinary context, it is more similar to DOS than to multiuser systems. That is a design choice. No sense in cluttering the system with access and / or security stuff when it is intended for embeded systems, and in fact can target markets where multiuser systems have problems to uphold strong security requirements because they rely too much on authentication with userids/passwords.
Re: Implementing users in a microkernel
Ok.. well regardless of other implementations. Heres what im currently thinking of doing. Comments welcome 
It is a multi-user multi-tasking microkernel.
A main restriction or goal is that no task can understand another, (encapsulation). The only way for tasks to communicate is via IPC. So as long as the single task is secure (address space protection etc), and the IPC is secure (Auth, etc). The system should be completely secure.
Single task security is all done within the kernel. Just leaving IPC.
For me, IPC is only data access (for now - i reserve the right to change my mind at any time
), So the only time IPC is needed is when data is shared. The 'server' task has to specify that some data is shared.
During initialisation of a task, keys are generated for all shared data (either each time the task is run or only on the first run).
When a 'client' task tries to access this data via the IPC, it must send its credentials. either in the form of a username+password, username+hash, or the raw key it has. When the IPC is initialising, the kernel checks that the IPC is allowed, and either rejects the call or creates it.
Mike
It is a multi-user multi-tasking microkernel.
A main restriction or goal is that no task can understand another, (encapsulation). The only way for tasks to communicate is via IPC. So as long as the single task is secure (address space protection etc), and the IPC is secure (Auth, etc). The system should be completely secure.
Single task security is all done within the kernel. Just leaving IPC.
For me, IPC is only data access (for now - i reserve the right to change my mind at any time
), So the only time IPC is needed is when data is shared. The 'server' task has to specify that some data is shared.During initialisation of a task, keys are generated for all shared data (either each time the task is run or only on the first run).
When a 'client' task tries to access this data via the IPC, it must send its credentials. either in the form of a username+password, username+hash, or the raw key it has. When the IPC is initialising, the kernel checks that the IPC is allowed, and either rejects the call or creates it.
Mike
Re: Implementing users in a microkernel
Is it? Why do you think PCI (Payment Card Industry) focuses on the loopholes of user authentication in mainstream OSes like Windows and Linux? It is simply because these systems are not safe, and in order to meet requirements there are a large amount of do and don't in order to use authentication and encryption so the result is sufficiently safe for use with credit-cards.berkus wrote:What a pile of bs.
It is nowhere near safe to just use user-authentication. This can be cracked in many ways:
1. By booting from a system that don't support user authentication
2. By collecting common userids / passwords on the net, and try to figure out a typical servers password. Because users cannot remember different userids/passwords to hundreds of sites, they reuse them, and thus this is highly effcient in order to break-into mission-critical systems.
3. Just protecting IPC won't do (what about files on disk?). Even if your particular OS won't allow login, another one might, and it might be able to read everything on disk if a common FS is used.
Re: Implementing users in a microkernel
Heya
* The harddrive is local (and so trusted as the kernel loaded the server) - This is handled transparently by the FS server/driver.
* The harddrive is remote but is trusted (with certificates) - Exactly the same as above, Encryption is transparent.
* The harddrive is remote but is not-trusted (public hosting/amazon storage etc) - The encryption must be dealt with locally (encrypted data stored remotely, decoded locally), as the link is IPC and dealt within the kernel, it can be transparent again via the distribution server.
Mike
Encryption is the only method to defend against this. You've got a few situations here and this is how i deal with them;rdos wrote: 3. Just protecting IPC won't do (what about files on disk?). Even if your particular OS won't allow login, another one might, and it might be able to read everything on disk if a common FS is used.
* The harddrive is local (and so trusted as the kernel loaded the server) - This is handled transparently by the FS server/driver.
* The harddrive is remote but is trusted (with certificates) - Exactly the same as above, Encryption is transparent.
* The harddrive is remote but is not-trusted (public hosting/amazon storage etc) - The encryption must be dealt with locally (encrypted data stored remotely, decoded locally), as the link is IPC and dealt within the kernel, it can be transparent again via the distribution server.
Mike
Re: Implementing users in a microkernel
I do not question your experience with ASM programming, but it seems you are quite confused about what constitutes a "system user" or a "multiuser system".rdos wrote:I wouldn't call it a single user system. There are many users (customers that fill up their cars), but each user can only interface with a payment application...
Every good solution is obvious once you've found it.