Tutorial:
Legion security

Table of Contents
About Legion security
How it affects your system
Enabling security
Special implications
Creating & working in a secure net
Adding users to a secure net
Shutting down a secure system
Other on-line tutorials & documentation
Click on the to move to the selected text.

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
The exact syntax will depend on what kind of shell you are using and where your Legion files are installed (i.e., the value of ~legion will depend on your individual Legion net). Consult your system administrator for more information.

The following style conventions are used in these tutorials:

About Legion security

Layers in Legion security model

 

There are two layers in Legion's security model (see figure, left). The message layer ensures that communications between Legion objects are secure. The MayI layer handles access control: it determines what objects (or users) are allowed to call a particular object's methods.

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

The message layer can protect individual messages, but it cannot stop an attacker from simply calling the methods of an object. The MayI layer (as in, "May I call this method?") has that job. When an object with a MayI layer is called, MayI examines the method call before the method is actually invoked. If the call passes MayI's access control policy, it is allowed. Otherwise, a security exception is returned to the caller.

Please see section 7.0 in the System Administrator manual for more information on the security model.


How it affects your system
When you enable 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.

Enabling security
You are not required to use Legion's security. Not all systems will benefit from it and Legion can run with or without security enabled. However, you must decide whether or not you wish to use security before you use a new system. If you create any new objects, change context space, run classes, etc., legion_init_security will not run correctly.

If you have a multi-architecture net, you will need to register implementations for each architecture (an implementation for your bootstrap architecture was automatically created when the system was first initialized). Use the legion_create_implementation command: 

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

To start security, run legion_init_security. Legion will create the /users context and the admin user id object. The admin user is the system's administrator: whoever is logged in and running the command will be the admin.

Once the command has finished, you must log in as admin. You must include the /users path. 

$ legion_login /users/admin
Password: xxxx
$
You are now ready to begin working.
Special implicationsAbout the AuthenticationObject
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.6.x 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.

Creating & working in a secure net
To create a secure net, you must start with a secure system. If you haven't already done so, start a new system and enable security. You'll then need to login as admin. You can then add hosts and vaults as desired.

Users can work in a secure net by entering: 

$ source <path_to_globally_visible_setup_script>/setup.[sh|csh]
$ legion_login /users/<user_name>
$ legion_cd /home/<user_name>
We suggest that you prepare a set-up script for your users to source when they wish to start working in your system. The legion_make_setup_script will automatically generate a set-up script for you.
Adding users to a secure net
To add users to a secure net, run legion_create_user (only admin can create users in a secure system). 
$ legion_create_user <user name>
Shutting down a secure system
The shutdown process is complicated for secure systems. There is no "root" user and each user owns his or her own objects. We suggest that you avoid trying to shut down a secure system unless absolutely necessary. Please contact us at legion-help@virginia.edu if you have any questions about this.

If you have only one user (i.e., /users/admin) and are using a basic host object on your bootstrap host, run legion_shutdown while logged in. You will probably need to clean up after the system by hand (i.e., kill the processes one by one from the command line: you can use ps to check that all Legion processes have been killed).

Other relevant on-line documents:
Click on the to go to the page.
Logging in to a running Legion system
Introduction to Legion context space
Context-related commands
Legion tty objects
Running a PVM code in Legion
Running a Legion MPI code
Running native MPI code 		Quick list of all 1.7 Legion commands
Usage of all 1.7 Legion commands
FAQs for running programs in Legion
Starting a new Legion system
Legion security
Legion host and vault objects
Adding host and vault objects
Brief descriptions of all on-line tutorials

Last modified: Thu Jun 15 16:28:28 2000

 

[Home] [General] [Documentation] [Software]
[Testbeds] [Et Cetera] [Map/Search]

legion@Virginia.edu
http://legion.virginia.edu/