6.0 Using security features

You are not required to use any of Legion's security options. We realize that not all systems will benefit from our security and we have therefore designed Legion to run with or without security. However, you must decide whether or not to enable Legion security when you first start your new system: legion_init_security (the command-line tool that starts the security mode) will not run correctly if you have added new hosts, started new classes, or created new users. If you do not run this command, you will still be able to run the system normally, but none of your processes will be protected.

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

If you choose to enable the security features (see Choose your security setting), you must run legion_init_security immediately after you have started a new system and you must log in as admin.

6.1 Creating new users

Please note that you must be logged in as admin in order to create new users in a security-enabled system.

You can now add users to your system, by creating user ids. A user id is an entry in context space that represents an AuthenticationObject. It is also used to signify ownership of all objects that a logged in user creates. Create user ids with the legion_create_user command.

$ legion_create_user user_name

The legion_create_user command is actually a simple wrapper around the legion_create_user_object command. The full command gives more control in creating AuthenticationObjects; execute it without arguments for a summary of its options.

Please allow about five minutes for the new user to propagate in your system after creating a user id. If you try to log in too early you will get security errors when you try to create objects.

You must also assign a password (this can be changed later: see Changing user passwords). A new user id is automatically given a new context in /home. If you create user id nemo, for example, a corresponding nemo context is created in /home.

$ legion_create_user nemo
New Legion password: xxxx 
Retype password: xxxx
1.3622a3eb.6b000000.03000000.000001fc...
Creating a Home context: /home/nemo
Creating context "nemo" in parent "/home".
New context LOID = "1.3622a3eb.05.11000000.000001fc..."
Changing ACLs on /home/nemo
$

Log in with legion_login plus the context path of the user object and password:

$ legion_login /users/user_name
Password:xxxx
$

On a successful login, a new shell is created. You must then move to your /home/user_name context with the legion_set_context command immediately after logging in*:

$ legion_set_context /home/user_name

While all users can "read" (i.e., look at and move to) all of the new context space, non-admin users can "write" (i.e., create new context objects) only in the /home, /etc, /tmp, /mpi, and /pvm contexts. Only admin can "write" in the all parts of context space (Figure 5). Log out is achieved by exiting the shell.

Figure 5Context space accessin a secure Legion system

The legion_change_permissions command can be used to alter "read," "write," and "execute" object permissions so that other users can use those objects. Please see About object permissions in the Basic User Manual or legion_change_permissions in the Reference Manual for discussion of this command.

6.2 Changing user passwords

A password can be changed with legion_passwd. Note that the context path or LOID of the user must be supplied as an argument:

$ legion_passwd /users/user_name

Either admin or the user can change the user's password.

6.2.1 More about legion_login

Like Unix rsh, legion_login can also execute a specific command rather than create a new interactive shell. For example, you can use legion_login to execute legion_cat on object bob:

$ legion_login /users/nemo -e legion_ping -c /home/nemo/bob
Password: xxxx
Bob's here.
$

With security enabled, nobody else can cat object bob except nemo. If nemo tries to cat bob while not logged in, he'll get something like this:

$ legion_cat /home/nemo/bob

Legion ExoEvent Caught:
Type        : "Exception:Security:MayI"
Description : "Security fault, MayI failed"
Source Loid : 1.3622a3eb.06.9bb12a36.000001fc...
Destination Loid : 1.3622a3eb.66000000.0400...
Function Id : _i_16exportsInterface_21LegionObjectInterface_V
$

Running while logged in has a benefit even if you do not plan to use security features. Normally, every command-line tool needs to create a public key pair for its self-generated LOID before it can do its work. When logged in, the tool gets the LOID from the legion_login process instead, which maintains several pregenerated LOIDs. On slow machines the time to generate a fresh LOID can be quite noticeable, so using legion_login eliminates some of the delay.

6.2.2 Changing implicit parameters and ACL information

There is a suite of four commands for manipulating implicit parameters and access control information.

To set the implicit parameters of a user while logged into that user, run legion_set_implicit_params and specify the user and the file containing the parameters.

$ legion_set_implicit_params -c /home/user_name file_name

Below is an example implicit parameters file that sets message security and an access control policy.

## Set up message level protection. Legal values are 
## "Protected", "Private", and "Off".
String MessageSecurity = "Protected"

## Set up an access control set and store it in the 
## specified implicit parameter.

Notes:

AccessControlSet {
	instanceOf /class/BasicFileClass {
		Method "read()" {
			allow bob fred
			## Only bob and fred can call this method 
			## (the class and instance can call it and 
			## grant certificates for it, too, of 
			## course-see note above).
		}

		Method "        LegionLOID ping();" {
				allow group
		deny fred
		}
		## The function identifier for this method 
		## includes the spaces within the quotation marks

		Default {
			allow bob unknown
			## All other methods are covered by this  case.
			## Suppose that bob is the one setting up this  
			## file. He probably wants to put himself in the 
			## allow list for every method he lists, as well 
			## as for the default. Of course, if he doesn't 
			## want access of a particular type (e.g., write
			## access), he can leave himself off. For any 
			## method where he grants access to unknown, he 
			## doesn't have to list himself. However, it 
			## doesn't hurt.
		}
   	}

	Default {
		Method "        LegionLOID ping();" {
			allow bob
			## Nobody can ping objects except bob
		}
		Default {
			allow unknown
		}
	}
}

Once the implicit parameters for a user have been set, you must log out and log in again for them to take affect. Alternatively, legion_set_implicit_params can be used to change the implicit parameters of the current session (if you do not specify a file name the command sets the implicit parameters of the current environment). If you do this, make sure that the implicit parameters contains a certificate definition for your AuthenticationObject, or you will have to log out and log in again in order to execute any further commands as an authenticated user. This documentation does not yet include an example of defining a certificate.

To show the current implicit parameters or the parameters for a particular user, use legion_get_implicit_params. Use legion_set_acl to change the access policy of an existing object: this is not the same as changing implicit parameters, which (in the case of access control) will only affect the creation of new objects. The legion_set_acl tool can have the same input file as legion_set_implicit_params but it only uses the access control information.

The legion_change_permissions command manipulates an object's ACL so that other users can call methods on that object.

If you have created a system with secure files, try creating a file as a logged-in user (the executable testBasicFiles will create a sample one for you). You can experiment with permissions and access control.

To get the names of methods available on an object, run legion_get_interface. The method names follow the output line titled Object Interface. Some of the methods are Legion object-mandatory functions, while others (usually listed at the end) are particular to objects of that class. You can cut and paste lines from the output into an implicit parameters file--put the names in double quotation marks in the Method definitions. Be sure to make your cut be from the real start and end of the line output by legion_get_interface, since some method names have leading or trailing tabs and spaces. Directing the output of legion_get_interface into a file then editing the file may be helpful.

If a user's AuthenticationObject is deleted there is no way to regenerate an equivalent AuthenticationObject; the user must be re-created from scratch. The reason is that the private key of the original AuthenticationObject cannot be recovered, so the same LOID cannot be used for the object.


* In the current release a user will be in the root (/) context rather than in his or her home context after logging in.


Back to System Administrator Manual Table of Contents

Directory of Legion 1.5 Manuals