Tutorial:
Using Legion security features

Table of Contents

  Other relevant on-line documents:

Logging in to a running Legion system Legion graphical user interface Introduction to Legion context space Context-related commands How to start remote programs in Legion Sample makefile for remote programs Object permissions Legion tty objects Running a PVM code in Legion

Running an MPI code in Legion Quick list of all Legion commands Usage of all Legion commands Starting and shutting down Legion 1.5 Using Legion security features Legion host and vault objects Adding host and vault objects The list of all on-line 1.5 tutorials

Depending on how your system is set up, you may need to set up your access to your system before you can run Legion commands. This will probably involve running a command such as this:

$ . ~legion/setup.sh

or

$ source ~legion/setup.csh

Figure 1: Legion security model

Legion's security model has two layers, shown in Figure 1. The message layer is responsible for ensuring that communications between Legion objects are secure. The MayI layer is responsible for access control, and it determines what objects (or users) are allowed to call a particular object's methods. It also relies on the message layer for some services, such as encrypting rights certificates.

The message layer intercepts every message that is sent from or received by an object. For outgoing messages, the layer uses the implicit parameters associated with the message to determine what security measures to apply. Implicit parameters here are similar to Unix environment variables, although their values are not restricted to strings.

Though the message layer can protect individual messages, it cannot stop an attacker from simply calling the methods of an object. The MayI layer fills this role. When an object that has a MayI layer is called, MayI examines the method call before the method is actually invoked. (The name of MayI comes from the idea that the caller is asking "May I call this method?") If the call passes the access control policy being enforced by MayI, it is allowed. Otherwise, a security exception is returned to the caller.

Please see the System Administrator Manual for more information on the security model.

When you enable security (by running legion_init_security) you will be given a system administrator user id called admin. This user id has root privileges in the system: it can create new users, modify security settings, etc. It also has ownership of all existing objects in the new system. Any objects that are created henceforth belong to the creator: in other words, if user bob creates object foo, only bob can use that object. The admin user does not own any other users' objects and must be given permission to use them (with legion_change_permissions).

When you create new users, with legion_create_user, a new context will be created for the new user in the /users context (i.e., /users/user_name). This can be used as the new user's home context. Note that users can only work in the /home, /etc, /temp, /mpi, and /pvm contexts. The admin user can work anywhere in context space.

Because Legion is a distributed system, some familiar concepts of traditional monolithic system security are different. For example, there is no central password file: each user's password is stored in the corresponding AuthenticationObject. Furthermore, any user can create an AuthenticationObject and create objects that no one else can call. There is still some control, though. For example, the system administrator may be the owner of an object that provides a resource such as printing. If that object looks in a particular group to determine access, and the system administrator has not added a user to that group, access will be denied.

We should note that Release 1.5 of the system has not been hardened to withstand attack. For example, by sending an appropriately mangled message, a sender can crash an object because the low-level message processing layers will not understand the headers. These changes are currently in progress.

To enable Legion security, run the legion_init_security command the first time that you start your system. Please note that Legion will run with or without the security features, but if you do not enable security none of your processes will be protected. If you don't enable it, you can simply start working in the system. Note, though, that you cannot turn on these features later. The legion_init_security command will not run properly unless you run it immediately after initializing the system.

To enable security, enter:

$ legion_init_security

Several events take place when you run this command, and we will discuss each in turn. First, a new context, called /users, is placed in the root context.

Creating the context "/users" to contain user-objects
Creating context "users" in parent "/".
New  context LOID = "1.3622260c.05.08000000.000001fc..."

The admin user is then created and given the context path /users/admin. You will also be asked to create a password. You will have to enter it three times. You can change it later, with legion_passwd.

Creating the initial system-admin user object, "/users/admin"
Please select a Legion password for "/users/admin":
New Legion password: xxxx
Retype password: xxxx
1.3622260c.6b000000.01000000.000001fc0c...
Please enter the Legion password for "/users/admin" to continue:
Password: xxxx

Legion then assigns ownership of all existing objects to admin.

Changing ownership of all objects to "/users/admin"
1.3622260c.01..000001fc0cbe1846763f895a...
1.3622260c.02..000001fc0b3b16eb8b2dde29...
[...etc.]
Changed ownership of 43 objects.

Then it creates and sets access control list (ACLs) for all existing objects.

Creating initial ACLs files for all core objects in
	/home/xxxx/OPR/init_acls
Creating ACL for /class/AuthenticationObjectClass class
Creating ACL for /class/BasicFileClass class
[...etc.]

Several new contexts are created and placed in the root context.

Creating context "tmp" in parent "/".
New  context LOID = "1.362dabd6.05.09000000.000001fc..."
Creating context "etc" in parent "/".
New  context LOID = "1.362dabd6.05.0a000000.000001fc..."
Creating context "mpi" in parent "/".
New  context LOID = "1.362dabd6.05.0b000000.000001fc..."
Creating context "programs" in parent "/mpi".
New  context LOID = "1.362dabd6.05.0c000000.000001fc..."
Creating context "instances" in parent "/mpi".
New  context LOID = "1.362dabd6.05.0d000000.000001fc..."
Creating context "pvm" in parent "/".
New  context LOID = "1.362dabd6.05.0e000000.000001fc..."
Creating context "tasks" in parent "/pvm".
New  context LOID = "1.362dabd6.05.0f000000.000001fc..."
Done creating acl files
Then it sets  the ACLs for all existing objects.
Setting ACL for /class/AuthenticationObjectClass class
Setting ACL for /class/BasicFileClass class
[...etc.]
All acls set.
$

You must now log in as admin. Note that you need to include the /users path.

$ legion_login /users/admin
Password: xxxx
$

At this point, security has been enabled and is running. You can create new user ids, create new host or vault objects, execute remote programs, etc.

If you are running a multi-architecture system, you will need to register other implementations for the AuthenticationObject (an implementation for your current architecture is automatically created when the system is first initialized). Use the following command on each different architecture:

$ legion_create_implementation \
  $LEGION/bin/$LEGION_ARCH/AuthenticationObject \
  $LEGION_ARCH -c /class/AuthenticationObjectClass
$