Re: [ANNOUNCE] Introducing Codezero

[Bas Wijnen]

Hi,

On Wed, Jul 01, 2009 at 10:10:25AM +0300, Bahadir Balban 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.
>
> 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.

I don't have enough idea about the code to know how good that would
work.  Does your kernel use dynamic memory itself, by the way?  In other
words, can the kernel get out-of-memory errors?

> 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.

Yes, that should not be much work.  I would expect no security-features
in the servers, because they simply cannot be contacted by untrusted
parties.  So if they get a request, it is always allowed.

> It should also be possible to pass along
> capabilities dynamically, though I would imagine most security
> permissions to be set up during initialization.

During any initialization, including the startup of a new process.  That
may eventually happen a lot on a running system.  (But not in this stage
of development.)

>> 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.

I would expect this to be very harmful for performance.  Either you have
a useful interface for everything (including stream and packet
transfer), but then the system will be over-designed for just about any
server, or you have a slim interface, and many servers will need to be
creative (read: slow) to fit their service to it.

> 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.

Capability management needs to be done during all initialization.  I'm
not sure what you mean by "mounting a new service on a process
namespace", but I suppose it means allowing access to a certain service
by a process?

Anyway, capability management happens for example during process
startup, when initiating new communication (and depending on the
implementation also for each message, but in L4 I think there are
sessions which means you don't pass capabilities all the time), and when
starting a sub-program, such as a plugin.

Apart from that, there's of course setup during system boot, but that's
irrelevant when looking at performance.

> What's better though, is that new and legacy services can co-exist in
> a flattened  hierarchy that doesn't increase system complexity.

If that means that you require every process to be able to access FS0,
thus in practice implementing global thread identifiers with which any
thread can communicate with any other thread, it is't better IMO. ;-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html

signature.asc
Description: Digital signature