JNode Security

Hi All,

I've been thinking about the topic of security lately. I believe this is one of the most important issues facing IT today, even microsoft think so (so they say). I also believe it can be an area where JNode especially shines. One thing to note however is that good security doesn't just 'happen' it has to be designed into the system.

So what is our security strategy? What facilities and protection do we offer to software run on the system?

I suppose at the first level we offer the security Java does. I would say this alone really sets us aside, but is this enough?

This may sound like a truism but security is all about restricting access. How does this apply to JNode? We'll I'd like to suggest a slightly different model:

All programs/plugins/drivers run in their own sandboxes.

What do I mean by this? Well at the moment a program can call system services to pretty much do as it likes.

Why not have a grant based model, so in an XML file read at component load time, the component describes which system components/interfaces it wants access to.

An example might be a graphics driver, it wouldnt need access to the filesystem or network, but would want access to the DMA controller. A map could then be passed on an interface to the component. The map would contain the interface names mapped to the actual interfaces passed. In this way we know exactly what a given component has access to. I would also be helpful in tracking down trojans. Rules can be enforced for particular types of component.

How does this sound? If people want me to clarify my ideas please drop a reply to this.

Java Webstart uses this concept, too

Submitted by monochromata on Fri, 12/17/2004 - 12:30.

After reading your text I realized, that Java WebStart uses this concept, too. They provide an API with a FileOpenService, FileSaveService etc. ...


http://java.sun.com/products/javawebstart/docs/javadoc/index.html

This API is available to all Java WebStart-enabled applications, also those that don't request java.security.AllPermission.

I was a bit sceptical after reading your message for the first time, because I thought it would lead to an overwhelming number of new interfaces. But if we create new interfaces only for the most common tasks this might make programming really easier. And everyone wanting the fully flexibility might of course use the existing APIs.

Sebastian

Very Interesting Article

Submitted by N8Dawg on Thu, 12/09/2004 - 12:46.

http://www.skyhunter.com/marcs/capabilityIntro/

It seems like I re-invented the wheel Smiling The concept is called capability based security. Please read the attached link. This is definately the way to proceed.

seems a good idea

Submitted by Fabien D on Fri, 12/03/2004 - 20:26.

I think picocontainer can be usefull to isolate a component from the others. It is based on dependency injection and interfaces.

Here is an example of code inspired from their example (in their 5 minutes presentation) and your example :
MutablePicoContainer pico = new DefaultPicoContainer();
pico.registerComponentImplementation(DMAControllerImpl.class);
DMAController dmaController = (DMAController)pico.getComponentInstance(DMAControllerImpl.class);

As you suggested, DMAControllerImpl could be declared to be used by the graphic driver in an XML file and so registered with registerComponentImplementation. And, now it can request access to the DMA controller with getComponentInstance

You can also see their sister projects

Fabien