Suggestions for a Secure Platform

Submitted by smartini on Tue, 01/18/2005 - 17:29.

Hi to all,
I've some ideas for JNode to be a Secure Platform, touching many low-level part of the System: SecurityManager, UserManager, ClassLoaders, InstallerService, Shell, etc.

Some ideas:
- JNode as s multiuser system with the ability to restrict logon only from local consoles, like is Linux
- no root account but use a User,Groups and Roles like in Tomcat, and grant permissions depending on the Role. For ex. any user that belong to the Administrators Group will have the Roles "System Manager, etc..."
- autologon (opt. enabled) in the installation or rescue process, but with an auto-scrambled password for security reasons, like in the Setup of Gentoo Linux. Autologon could be useful also later.
- implement the Security System with apluggable system in mind, like PAM and JAAS, so having a default implementation for (machine) local users/group/roles, and later other implementations for Windows Domains (via LDAP), NIS Domains, etc.
- opt., enable some limits (CPU, memory, num process, disk space) for applications and users
- default Security Policy with the permission for the various packages, for ex. org.jnode.* can interact directly with the Hardware, but must be in a signed (by JNode developers) jar, and so on for java.*, javax.*, etc as specified in the System Policy
- SecurityManager and ClassLoader linked to the main role of a User. For ex. a Developer could have a SecurityManager that doesn't want any Class org.jnode.* to be in a signed (by JNode Developers) jar, giving some warnings ... but attention to this. For a normal user this could be blocked by default.
- execution of commands/applications, only from packages installed by the InstallerService (that could inspect any class/jar to install and create aliases only for the correct classes with a main method, listed in the manifest, etc). But for Developers this could be different, there could be a Wrapper.
- any application installed could have visibility only of the part of disk where the InstallerService has installed it (plus a temp dir, and the command aliases, and some link to global jars), so no other programs could be infected for ex by a Virus. No absolute references to the disk. The problem now is how to protect the User Home from a dangerous application, but for ex. we could force an application to write only some file extensions in that area ...
This could also be applied to the execution of any application, with a virtual user (created by the InstallerService for the installed apllication)which has only that limited access to resources (opt. limited also by FileSystem permissions).
- Classpath across multiple applications ? Or better from any application to some links to other global jars ?
- etc ...

How to map this with the current implementation plugins-based ?

What do you think ?

Bye,
Sandro

‹ jnodesys.gz renamed to jnode32.gz Startup time ›

Requirements first

Submitted by monochromata on Fri, 01/21/2005 - 19:00.

Hi Sandro,

you already provide a very detailed list of as you say 'low-level parts'. Before diving into these details I would be interested to hear from you and others what requirements you have for Jnode. I think everyone will agree that Jnode should be a secure system. But besides this there may be a number of other important questions that will equally influence the 'low-level parts'.

I already mentioned usability a few times before. I know that currently and for quite some time, Jnode will only be used by developers. But I think we should also think about normal users and if it is desireable to make Jnode as simple and usable as possible. If others agree that this is a good idea, then we might come to the conclusion that e.g. 'low-level parts' like role-based permissions are indeed of great value for security, but not for usability.

This does not mean that we should simply do it without role-based permissions, but we should at least seek for another solution that adequately reflects both the goals of security and usability.

Sebastian