Previous Up Next
Previous Up Next
Encrypted Passwords in enfuzion.nodes
User Defined Decryption Primitives
enfuzion.security
On Unix, enFuzion requires that standard telnet and ftp
protocols are operational between the local and remote systems.
Alternatively, rsh and rcp can be used.
On Windows NT, an enFuzion Starter Service is included with enFuzion
to provide similar functionality.
enFuzion hides the management of the network. After enFuzion is installed on remote computers, node servers are automatically started and terminated as required. No system management tools with special privileges are required on the local or remote systems.
The Dispatcher requires a configuration file, usually called
"enfuzion.nodes" in its working directory. This file contains
the name and login information for each remote computer to act as a
enFuzion Node. The login information consists of a user name, an optional
password and an optional remote access to the remote Node.
Each line in "enfuzion.nodes" has the following format:
hostname username [ password ] [ remote_access ]
Lines that start with "#" are treated as comments.
You can specify the sharing of the same password among several computers. In networks with large number of nodes, this feature can significantly reduce the typing of passwords. When a computer has the password that is already specified for a previous computer in the configuration file, write its password as a "$" sign, followed by the previous computer's name. In this case, enFuzion will ask for the shared password only once.
An example:
host1.domain.com username
host2.domain.com username $host1.domain.com
host3.domain.com username $host1.domain.com
host1.domain.com, host2.domain.com and host3.domain.com all share the same password. After enFuzion prompts for the password for host1.domain.com, it will use the same password for host2.domain.com and host3.domain.com.
Encrypted passwords are also accepted. See "Encrypted Passwords" for details.
enFuzion provides three ways of specifying access to a remote host:
If the operating system on an enFuzion Node is of a different type than the operating system on the Root, then remote access must be specified in the configuration file. A Windows NT host is specified with "WindowsNT". A Unix host using telnet protocol is specified as "Unix" and Unix host using rsh protocol is specified as "UnixRsh".
An example:
host1.domain.com username WindowsNT
host2.domain.com username Unix
host3.domain.com username UnixRsh
localhost
Strings "WindowsNT", "Unix" and "UnixRsh" are always recognized by enFuzion as the remote access type. If these strings are used as passwords on remote hosts, it is impossible to specify them as passwords in the configuration file. They must be entered interactively.
If jobs are executed on a local node, enFuzion does not need remote access type, username and password.
If the remote access type is UnixRsh, then enFuzion assumes that no password is required for the host. Accordingly, no prompt is issued for the password at runtime.
Local mode is useful for testing purposes. Plan files can be tested without increased complexity of distributed execution.
A complete set of load monitoring features is available under the local mode. This can be useful to execute jobs on the local computer, while observing interactive host usage. For example, job execution can be terminated when the host is used interactively and resumed when the host becomes idle.
Local nodes are specified in file enfuzion.nodes
with the string localhost as the host name. Username,
password and remote access type are not required.
Local execution is currently supported only on Unix host types.
hostname [domainname\]username [ password ] [remote_access]Username and domainname are used to make initial installation of enFuzion on Windows NT nodes.
A domain name is optional and if not specified, a local domain is used.
enFuzion assumes that the user has accounts on remote computers. Programs on remote computers are run under the username given in the configuration file. They inherit all access rights of that user.
enFuzion uses standard Internet protocols to communicate with remote computers: TCP/IP, telnet and ftp.
On Unix, enFuzion nodes on remote computers are started transparently to the user, using the Telnet protocol. On Windows NT, an enFuzion Starter Service is provided for starting enFuzion nodes. The nodes will have access rights of the user, under which they run. Remote login passwords can either be stored in a configuration file or entered interactively by the user as required. Besides login access, no other special privileges are required to install and use enFuzion on Unix. On Windows NT, login access is sufficient to use enFuzion. However, Administrative rights are required to install enFuzion on Windows NT.
enFuzion provides several security features to enhance standard
security provided by Unix and Windows NT systems. These features
enable increased security in accessing remote hosts. They include:
encryption of information in enfuzion.nodes, authorization
of trusted hosts and executables, and user defined decryption primitives.
These additional security features are described in the following sections.
enFuzion provides trusted hosts and trusted executables. Only trusted hosts are allowed to access an enFuzion Node. Only trusted executables are executed by enFuzion on the Node.
Trusted hosts and trusted executables are specified in file
enfuzion.security. A system security file and a user
specific security file can be located on each host.
On Unix, the system security file must be located in directory
/var/opt/enfuzion and the user security file in
directory ~/.enfuzion/enfuzion.security.
On Windows NT, the system security file must be located in directory
C:\enfuzion\enfuzion.security. User security files are
not supported on Windows NT.
Security files are handled as follows:
If a security file exists, no hosts and no executables are trusted,
unless specified otherwise in the file. An exception is the local host
which is always trusted.
An empty enfuzion.security file therefore specifies all hosts,
except the local host, and executables as not trusted.
Security files are text files containing a list of security specifications. Each line represents one specification. Comment lines are denoted by "#" at the beginning of the line.
The syntax of a security specification is:
<security_status> <resource_type> <resource_name_list>
The security_status can be either allow or deny.
allow specifies a list of trusted resources.
deny specifies a list of resources not trusted.
For example, the following lines specify enFuzion Root hosts pluto
and mini as trusted and host garfield as not trusted:
allow host pluto, mini deny host garfield
The resource_type specifies the type of resource for which
security status is specified. resource_type can be one of
host or executable. For example, the following
line specifies executables echo and ps as trusted:
allow executable echo, psThe
resource_name_list contains a comma separated list of resource
names. The '*' denotes all resources of given type. For example, the following
line specifies all executables as trusted:
allow executable *
If the resource type is host, the names of hosts in a list
can be either Internet IP addresses or official host names.
Internet IP addresses have the format d.d.d.d,
where d is a decimal number or character '*'.
The character '*' stands for any number.
An official host name consists of a host name and an optional domain name.
The '*' as a host name denotes all hosts.
For example, the following line specifies all hosts
on the network 192.166.2 as trusted:
allow host 192.166.2.*
Important Note! The use of IP addresses is strongly recommended. If official host names are used instead, they can cause significant delays in enFuzion operation. It can take up to several minutes to resolve an official host name in certain networks.
The order of security specifications in a security file is important. All the specifications in the security file are verified for a given resource and the last status is taken as valid. For example, the following lines specify host strippy as trusted:
deny host strippy allow host strippy
The following lines specify host strippy as not trusted:
allow host strippy deny host strippy
The enfuzion.security file containing the following lines
specifies all hosts running any executables as trusted:
allow host * allow executable *This is equivalent to no security file being specified.
execute $HOME/bin/enfechoIn the example above the full path of the command is not determined until the whole line is executed by the shell. Therefore the security status of the command can not be determined and the command is rejected. The command must be rewritten as follows:
execute /home/myuser/bin/enfecho
enfuzion.nodes
enFuzion Nodes on remote hosts are specified in file enfuzion.nodes,
as described in Network Configuration File.
Normally, each Node is described with a line, containing user and password
in cleartext. This storage of cleartext passwords in a file can compromise
system security. To avoid this security problem, enFuzion provides mechanisms
to encrypt password information. Passwords can be either encrypted by a
default enFuzion method or by a user provided method.
The Dispatcher provides a method to encrypt sensitive information in
the network configuration file, called enfuzion.nodes by default.
The Dispatcher takes a cleartext network configuration file and provides
its corresponding encrypted version. This encryption is done simply by
specifying -e option in the command line.
For example:
enfdispatcher -e simple.runThis option creates file
enfuzion.nodes.e, which contains
encrypted node information from the network configuration file. In this file,
passwords from the input file are replaced with encrypted fields, starting
with "***".
Cleartext passwords in the original configuration file can be changed to
encrypted fields either by renaming the entire enfuzion.nodes.e
to enfuzion.nodes or by manually replacing cleartext
passwords with their corresponding encrypted fields.
Important Note! Encrypted fields contain more than just password information. Whenever any information, such as a user name or a password, in the original network configuration file changes, the encrypted file must be generated again.
The following enFuzion programs are able to read the network configuration from standard input:
enfdispatcher upgrade (on Windows NT only) enfkill (on Windows NT only)
Option "-d" turns on the reading of the network configuration
from standard input for all the programs above.
Example:
user_decrypt enfuzion.nodes.user_encrypted | enfdispatcher -d simulation.run
User encryption using standard input is not supported by the
Unix installation program enfinstall, because the
program requires interactive input.
This feature is supported only on Windows NT.
enfuzion.security. The library provides an interface, which
specifies decryption functions, called by enFuzion.
The library must have the filename "enfuser.dll".
The .dll file which is usually in the directory "C:\enFuzion\bin" must be in the search path of each enFuzion Node.
The library is loaded at the program startup. If a new version of the library is provided by the user, all enFuzion programs that use the library must be restarted. The programs affected are Starter Service and Node Server.
enfuzion.security.
The following interface functions are defined for "enfuser.dll":
int decryptPassword(char *passin, int inlen, char *passout, int outlen);
void *openFileDecryption(char *filename);
int readNextDecryptedLine(void *fid, char *buffer, int buflen);
int closeFileDecryption(void *fid);
If a function is not found in "enfuser.dll", then its
default version is called.
A binary dump of "enfuser.dll" produces the following
output:
d:\enFuzion\bin> dumpbin -exports enfuser.dll
Dump of file enfuser.dll
...
File Type: DLL
Section contains the following Exports for secdemodll.dll
...
ordinal hint name
5 0 __DebuggerHookData (000021BC)
3 1 _closeFileDecryption (000014BE)
4 2 _decryptPassword (000014D7)
1 3 _openFileDecryption (00001480)
2 4 _readNextDecryptedLine (00001495)
Notice that names of library functions are preceded by underscore, "_".
Because "enfuser.dll" is used also by processes running in the
background, functions should not write to standard output or
standard error streams.
Details of the interface functions are described in the next section.
enfuzion.nodes. These passwords
can be in a cleartext form or encoded by enFuzion, as described in
"enFuzion Encryption".
The user can replace cleartext passwords in enfuzion.nodes
with encrypted passwords. Encrypted passwords must consist of
non-white, printable ASCII characters. These passwords will be decrypted by
calling function decryptPassword() from the dynamic library
"enfuser.dll". If "enfuser.dll" is not found
or decryptPassword() is not defined, then no user decryption
will be performed.
Function decryptPassword() provides the following interface:
int decryptPassword(char *passin, int inlen, char *passout, int outlen);
passin is a pointer to the user encrypted
password from enfuzion.nodes.
inlen is the number of valid characters in passin.
passout is a pointer to the decrypted password. The decrypted
password must contain non-white, printable ASCII characters, terminated
by a null character, '\0'. This string will be used as a password to perform
a login on the remote host.
outlen is the length of the passout buffer,
available for the decrypted password.
The function implementation must handle passout buffer overflows.
The function returns 0 on success or a negative user defined error code
otherwise.
Currently, enFuzion provides passout buffer of size 1024
characters, that is outlen equals 1024.
User encrypted passwords can be decrypted by enFuzion, but not the opposite.
enfuzion.securityenfuzion.security can be
encrypted by the user. enFuzion uses the following functions from
"enfuser.dll" to decrypt the file.
void *openFileDecryption(char *filename);
Returns a handle to identify an encrypted file. NULL is returned on error.
Currently, enFuzion calls openFileDecryption()
with filename parameter containing an absolute path
of the enfuzion.security file on the host.
int readNextDecryptedLine(void *fid, char *buffer, int buflen);
Reads the next line from the file. Returns the number of bytes read
or a negative number if error. Return value of 0 indicates an end of
file.
Currently, enFuzion provides buffer of size 1024
characters, that is buflen equals 1024. fid
equals to the handle, returned by a previous call to
openFileDecryption().
int closeFileDecryption(void *fid);
Closes the handle. Returns 0 on success and -1 otherwise.
fid equals to the handle, returned by a previous call to
openFileDecryption().
If a function is not defined in "enfuser.dll", then its
default version with no decryption is called.
/*
* Sample implementation of security dll: "enfuser.dll"
*/
#include <stdio.h>
#include <string.h>
/*
* Decrypt password
* return 0 on success
* -1 on error
*/
int _export decryptPassword(char *password, int passlen,
char *decryptedpassword, int decpasslen)
{
if (strlen(password) > decpasslen) {
return -1;
}
strcpy(decryptedpassword, password);
return 0;
}
/*
* Return a handle to decrypted file
* or NULL on error.
*/
void * _export openFileDecryption(char *filename)
{
return(fopen(filename, "r"));
}
/*
* Read next decrypted line
* Return number of characters read
*/
int _export readNextDecryptedLine(void *fid, char *outbuf, int outbuflen)
{
if (fgets(outbuf, outbuflen, fid) == NULL) {
return 0;
}
return strlen(outbuf);
}
/*
* Close handle to decrypted file
* Return 0 on success
* -1 on error
*/
int _export closeFileDecryption(void *fid)
{
if (fclose(fid) != 0) {
return -1;
}
return 0;
}
Previous Up Next