Re: [ANNOUNCE] Introducing Codezero

Bas Wijnen wrote:

> I'm not sure if "adding capabilities" to a working system is a proper
> way to get security right.  Security is not something that can be added
> to a program.  It must be at the core, and the design must support it
> from the start.
>
> If you try to add it, I fear that either it will not work, because there
> are insecure bypasses for secure parts, or it will have bad performance
> because the fast paths of the system aren't used, or both.

Hi Bas,

Implementing fine-grained access control mechanism inside the
microkernel should take no more than a week or two. I would imagine all
I would need to do for the first version is to add a per-thread bitmap
structure that controls resources such as the amount of virtual/physical
memory, cpu time, with whom the communication is allowed, which
requests, what type of ipc ... etc.

Securing the existing communication may take some effort, although it
should not be too difficult. There are only 2 servers and a handful of
requests. I think I will have part of the above implemented on the next
version of Codezero. It should also be possible to pass along
capabilities dynamically, though I would imagine most security
permissions to be set up during initialization.

> What I've seen from capability systems, they can be seen by object
> oriented systems as remote object calls.  However, this is not enforced
> in any way.  The kernel just sends a message over a protected channel.
> How this is used or interpreted by both ends of the channel is their
> problem.

In my plan, there will be servers, (i.e. C programs) that simply do IPC
in a controlled fashion. The design won't be centered around
interface/implementation type of remote object instantiation as you 
would see in say, Corba, Java RMI etc. This is because the goal is to 
reduce interfaces down to a minimum generic set of calls such as 
open/close/read/write ... just like in Plan 9. So instead of having a 
different interface for each object, there will simply be a file-based 
interface for everything.

> Turning a capability-based system into something like Linux is easy[1]:
> just build a central file system server and give a capability for it to
> all processes.  Turning Linux into a capability-based system is
> equivalent to rewriting Linux.

Yes sure. Although I envision that in a new capability system, most 
capability management can be done during the mounting of a new service 
on a process namespace. Correct me if I am wrong.

> > FS0 has the VFS and the underlying filesystems bundled.
>
> In one server?  Does that mean that a new FS0 is needed to support a new
> file system type?  I would advise to use a system where users can use
> their own implementation of file systems, without the help of the system
> administrator.  But that may just be my Hurd-mind, and not something you
> wish to care about. ;-)
>
> Thanks,
> Bas

This is possible. Currently, FS0 only provides an abstract interface to
access a real, low-level filesystem underneath. There is no mount
support yet, and this is because I haven't decided on how to do it the
best way. My expectation is that there is going to be standalone file
servers that are attached to the namespace of each process. FS0 will
take care of the main handling of the namespace management. For example
a driver, a communication stack, or a standalone filesystem will be able
to run this way. However, I also want to keep the option of having the
real filesystems bundled to FS0 for performance reasons.

Generally my thoughts are centered around building a microkernel-based
OS for embedded systems using Plan 9 design principles. What's better
though, is that new and legacy services can co-exist in a flattened 
hierarchy that doesn't increase system complexity.

Thanks,

--
Bahadir Balban