A Sysctl server provides remote access to a set of commands for authenticated and authorized clients. Since the Sysctl server is running with UID 0, these commands are executed with root privilege. These commands are embedded in an interpreter within the server. Sysctl uses the Tool Command Language (Tcl) as the foundation for its built-in command interpreter. The commands are of the following types:
These are the commands making up the Tcl language. They include control commands (such as if), input/output commands (such as puts), arithmetic commands (such as expr) and commands allowing the execution of other commands, including external AIX commands and scripts (exec).
These are provided for you. They include commands to configure and manage Sysctl, as well as some systems management applications. See Built-in Sysctl commands.
The Tcl interpreter that Sysctl uses is built from base Tcl and Extended Tcl. Refer to the ssp.public.README file for more information on Tcl as supplied with the SP.
Using an embedded language, particularly Tcl, provides the following advantages:
The management tools used to administer a large site need to be secure to prevent outside intrusion and to prevent accidental disasters, such as inadvertently deleting critical data.
Sysctl has the following security components:
An access control list (ACL) is a text file that can be used to grant authority to particular users to issue particular commands. Sysctl provides ACL-based authorization. See Sysctl files for more information.
The security services supported on the SP system provide trusted third party authentication of users. When a client issues a Sysctl command, client credentials are sent along with the command. The server uses that information to identify and authenticate the identity of the client.
Identification and authentication are procedures that a client and server use to verify their identities to each other. The objective is to provide an identity that the server can use for authorization. The way that identification and authentication take place is determined by the security policy established by your organization and implemented by the SP system and security administrators, as well as by the actions taken or not taken by an individual user. SP systems running PSSP 3.2 can be configured to support any of the following combinations of authentication methods for SP trusted services:
When one or both authentication methods is used for SP trusted services, as an authorized administrator, you must create principals in the authentication database to represent the clients. For the purpose of authentication, a client command uses the principal name of the user who is running it. Servers use service principal names that are predefined during system configuration. To establish how users obtain credentials so they can submit Sysctl requests as authenticated clients, do the following:
A user of the Sysctl facility can submit requests for remote execution as an unauthenticated AIX user or as an authenticated principal. The Sysctl client command obtains and forwards to the target server, the AIX user name that submitted the command as an unauthenticated identity, plus whatever authentication credentials are available. The client might have a DCE identity, a Kerberos V4 identity, both, or only the unauthenticated AIX identity. The server then tries to establish an authenticated identity for the client. Depending on which authentication methods are enabled and the availability of valid credentials, the server first tries a DCE principal, then a Kerberos V4 principal, and finally the AIX user name. When authentication succeeds using DCE, the server does not use other credentials submitted by the client. Authentication of the client by the server might fail because the credentials are invalid, the credentials are expired, or the server host is not configured to support any of the authentication methods enabled for the SP trusted services.
However do not infer, without investigating further, that a reported authentication failure was actually the reason for a denial of access. Denial of access can be caused by things other than authentication failures, such as the following:
Given the flexibility in configuring security services on the SP system, the possibility that you might install and configure the SP security services client facilities on independent workstations, and the support for coexistence and interoperability of PSSP 3.2 with earlier versions, your SP system can have a complex security environment with multiple hosts configured differently. Though Kerberos V4 is now optional, unless you have a brand new SP system using PSSP 3.2 with only DCE authentication, Kerberos V4 must be configured in order for authentication to succeed. When the compatibility authentication method is in use on the system, but DCE is not, users must have Kerberos V4 credentials to use Sysctl facilities that require an authenticated identity. This is also true when any node is running with a PSSP release earlier than PSSP 3.2.
When all hosts are running PSSP 3.2, you do not have to configure and use any authentication methods for SP trusted services if the security policy of your organization allows access by unauthenticated clients. Where clients are allowed to be unauthenticated anonymous users, users can access Sysctl servers without regard to the security configuration. When used in this fashion, Sysctl provides no protection from unlimited access to root privileges on the server system. Avoid that mode of operation except, for example during initial installation, when all hosts are physically isolated from the network and access to the system is limited to authorized administrators.
When a user submits a Sysctl request, the process establishes the identity of the client, then that identity is used to determine whether the client has permission to do what is requested. The client can have any of the following forms of identity for authorization:
After the identity is established, the server uses the following authorization steps by default:
Unless you have reconfigured Sysctl without an svcconnect procedure, each request must be authorized by that procedure before proceeding to the second step. The default svcconnect policy is to allow requests only from authenticated clients when any authentication method for SP trusted services is used on the server host, and to allow all requests on hosts with no authentication method in use for SP trusted services. See the svcconnect Sysctl procedure for information on overriding the default policy.
After a request passes the first authorization step, access rights are determined by how access control is defined for individual Sysctl resources on your SP system. Sysctl supports multiple authorization methods. The most widely used and most flexible is based on access control lists. Each Sysctl procedure and read-only variable is associated at server configuration time with a Tcl procedure called an authorization callback. Basically, it is a procedure that Sysctl invokes immediately before accessing the object it protects, to determine whether to allow that access. It can use the identity of the client and server state information stored in predefined Tcl variables to make its decision. Apart from the predefined callbacks, Sysctl allows the author of a Sysctl procedure to provide a unique callback based on arbitrarily defined factors.
IBM provides and uses four predefined authorization callback procedures. You can also use them as they are, change them, or write others. The predefined callback procedures are the following:
When the ACL callback is used to authorize a DCE principal, the name of the ACL in the callback specification is the name of a DCE object known to the DCE ACL management functions in the Sysctl server. When Sysctl is configured, each ACL object referenced by authorization callbacks is created by the server, if it did not previously exist. Each object has an owner that has control access (c permission) which grants the right to modify the ACL. The default owner for ACL objects is the spsec-admin group. This group is defined when PSSP is configured in the DCE cell, with the DCE cell administrator as its only member. The cell administrator must add other members to the group, as required by local security policy.
Members of the spsec-admin group use the DCE dcecp command to create, change, remove, and list ACL entries. The dcecp command requires references to objects to be fully qualified CDS names, consisting of the cell name (or the string /.: to denote the local cell), the CDS directory path for the RPC entry for the server, and the residual object name. For Sysctl, the CDS path to the Sysctl server on DCE host DCEhostname is /.:/subsys/ssp/DCEhostname/sysctl. The object name appended to the CDS path is the name in the ACL callback specification. For the permissions related to Sysctl objects, see Permissions in Sysctl ACLs.
To add an entry for DCE principal sarah to the problem management ACL on the node whose DCE hostname is node8, for example, an authorized administrator would execute the following dcecp subcommand:
acl modify /.:/subsys/ssp/node8/sysctl/etc/sysctl.pman.acl \ -entry -add user:sarah:at
When an ACL callback is used to authorize a request by a client other than a DCE principal, the name of the ACL is used as the fully qualified path name of an ASCII format file in which you have created ACL entries. If the callback is {ACL} with no path name, the default file defined by the $ACL variable is used. You create ACL entries in these files using built-in Sysctl procedures or an editor of your choice. Since the authorization callback for the acladd command is {ACL}, the entry in the default ACL file cannot be added using acladd, unless the user is authorized using DCE (such as by being a member of the sysctl-master DCE group).
When the server is running with both DCE and compatibility authentication methods active, it is only necessary to be authorized by either DCE or Kerberos V4 authentication. To avoid confusion, you might want to keep the authorization information in the DCE ACLs and groups consistent with information in the Kerberos V4 Sysctl ACL files. For example, to add an entry for Kerberos V4 principal sarah to the problem management ACL on all hosts listed in the /tmp/sphosts file, you might use the following command:
sysctl -c /tmp/sphosts acladd -f /etc/sysctl.pman.acl -p sarah
To use the acladd command, you would have to be authorized for global Sysctl access by an entry in the /etc/sysctl.acl file. Another way is to edit the files directly, but you would have to log in as root on each host to do it.
ACLs provide the most flexibility in implementing your access controls. The ways to authorize a client request differ depending on the form of identity established at the server. Note that a given client can have different identities for the same request on different target servers, since the identity is determined in part by the capabilities of the server.
A client authenticated using DCE can be granted access by the following:
A client authenticated using Kerberos V4 can be granted access by the following:
An unauthenticated client can be granted access by the following:
There is an entry defined in the Sysctl ACL file that allows access to all unauthenticated users. This applies to requests from clients who have no Kerberos V4 or DCE credentials as well as to requests submitted using the command line option to bypass authentication.
In some situations, the server bypasses the authorization callbacks. Authorization callbacks are bypassed while the server does the following:
The executables are:
The Sysctl server daemon, sysctld, processes all Sysctl client requests for the node on which it runs. There is a sysctld daemon running on each node of the SP system, as well as on the control workstation. The sysctld daemon runs as root and executes Tcl procedures for authenticated and authorized clients who may be local or remote users. See the sysctld man page for more information.
The Sysctl client shell program, sysctl, offers a command line interface for communicating with sysctld. Together, sysctl and sysctld provide monitoring and execution abilities needed to remotely manage SP nodes. sysctl connects to a remote node's sysctld using TCP/IP, passes keywords and commands to the server, and writes any output returned to stdout and stderr. See the sysctl man page for more information.
The Sysctl server files include the following:
A configuration file is provided when Sysctl is installed on the control workstation and on each SP node. The default path name for this file is /etc/sysctl.conf. The configuration file modifies the state of the server by executing one or more configuration commands. The configuration commands create read-only variables, register procedures, include other configuration files, and create classes of commands.
You can customize Sysctl servers by manipulating this configuration file. Initial configuration takes place each time the sysctld daemon is started on an SP node or control workstation. When the PSSP software is installed, a script creates the sysctld subsystem under SRC control and adds an entry to the inittab to start it at boot time. When started, the daemon sets up its Tcl interpreter tables to contain the built-in procedures supplied with the product. Then it executes the /etc/sysctl.conf file, which is a Tcl script that invokes Sysctl procedures to create additional Sysctl objects (procedures, variables, and classes) that are provided for managing the SP system.
You can tailor the configuration file after initial installation to make your own additions or changes to the base Sysctl facilities. You can insert Sysctl and basic Tcl procedures that create new objects or change existing objects. You might prefer to create a separate customization script and add it to the default configuration file with an include procedure that names the new script. That method is used by the log management component of PSSP to add its Sysctl configuration information to the server.
You can use the create proc built-in procedure to add new procedures and the setauth built-in procedure to change the authorization callbacks assigned to already configured procedures. Authorization callbacks are bypassed during configuration, allowing any built-in Sysctl procedures to be invoked from within configuration scripts. For security, only root should have write authority to Sysctl configuration files, including any that you create.
When you assign an authorization callback procedure, the server does not check to see whether it exists. The following messages generated using the security auditing option show successful setting of a nonexistent callback:
Sep 10 10:30:55 AUDIT[cmd]: Creating procedure xxtest, callBack = {NoAuth}
Sep 10 10:30:55 AUDIT[sec]: Setting callback for command "xxtest" => {NoAuth}
When you try to use the procedure or variable protected by a nonexistent callback, however, the error will simply be reported as an authorization failure. If you run with security auditing turned on, messages like the following should be recorded in the server's log file:
Sep 10 10:31:17 <37d91620> AUDIT[tcl]: Evaluating: xxtest
Sep 10 10:31:17 <37d91620> AUDIT[sec]: Checking object authorization
callback for command "xxtest": NoAuth
Sep 10 10:31:17 <37d91620> AUDIT[sec]: interp>result from object
callback {NoAuth} = "Not a valid command name: "NoAuth"", retCode = 1
Sep 10 10:31:17 <37d91620> AUDIT[sec]: Authorization denied for command "xxtest"
See Sysctl installation and configuration information, the sysctld man page, and the sysctl.conf man page for more information about configuring your system for Sysctl.
The following ACL files that Sysctl uses are provided:
This identifies trusted users for servers. Trusted users are authorized to run any Sysctl or Tcl procedure, except for those with the SYSTEM authorization level. Trusted users have privileges equal to those of a root user.
You can create ACL files to customize existing Sysctl facilities or add new ones. For example, you might designate a set of users that can issue a particular Sysctl procedure by creating an ACL for that procedure. The authorization callback of the procedure can be set to reference your ACL.
The ACLs that Sysctl uses to authorize requests by authenticated DCE principals are not individual files that you manage directly, but data maintained by DCE and the Sysctl server in a database. There is an SP ACL management component of PSSP. You can manipulate the entries in the ACLs by using the SP ACL management or by using the standard DCE ACL management tools such as the dcecp command. Your interface to SP ACL management includes the spacl command and the spauth_spacl SMIT fastpath. See Managing DCE ACLs for SP trusted services.
If you use the DCE commands you must refer to the ACL using a fully-qualified CDS path of the server with the ACL name, as specified in the callback, appended to it. See the description of the ACL callback in Built-in authorization callbacks for details. Because DCE ACLs are managed by the server that owns them in cooperation with DCE, sysctld must be running in order to issue dcecp subcommands that reference Sysctl ACLs.
DCE requires that all ACLs have at least one entry that grants control (c) permission: the authority to manage the ACL. All ACLs used by Sysctl are created with an initial entry that grants control authority to the spsec-admin DCE group. The group and initial members are established when the PSSP software is installed and configured. Unless the name has been locally overridden, the DCE cell_admin user principal is a member by default. Though you can create additional ACL entries granting control permission, the easiest and preferred method is to add members to the spsec-admin DCE group.
All other entries use only three permissions:
Sysctl uses the following ACLs when the DCE authentication method is in use:
This ACL is created when Sysctl is started on the system. It initially contains one entry for the spsec-admin DCE group already discussed and another with a and t permissions for the sysctl-master group. No members are predefined for this group. You can add DCE principals of persons who are trusted to use all Sysctl facilities, including the ability to reconfigure Sysctl. If you do not give this level of authority to at least one DCE principal, the procedures that use the default ACL callback for authorization will not be available to anyone unless you redefine the callbacks by customizing the Sysctl configuration.
Like the global ACL, these are also created with an initial entry for the spsec-admin DCE group. Other entries are defined by the individual subsystem that uses them. The authorization instructions for each subsystem indicate how you can tailor these ACLs.
You do not create a DCE ACL directly. The Sysctl server creates it automatically, while processing the configuration file, when it first finds a reference to it in an ACL callback. As with the predefined ACLs, it creates an entry for the spsec-admin DCE group. Therefore, first you update the configuration file to use an ACL callback that references the new ACL that you want to create. Then restart Sysctl. Then you can update the new ACL file using the dcecp command to create all other entries.
If you write a callback that invokes the acl check procedure rather than using the ACL callback with your locally created ACL file, Sysctl will not recognize your ACL definition and will not create the new ACL. If you want to define an ACL of that nature, define a dummy variable with {ACL your-acl-name} as its callback. For example, specify in the configuration file:
create proc z_callback {} NONE {
.. if {[aclcheck -f /var/z/acl]} {..} ..
}
create proc z_proc {..} z_callback {..}
create var z_var {} {ACL /var/z/acl}
The following example uses the dcecp command to add an entry and show the contents of an ACL:
dcecp -c acl modify /.:/subsys/ssp/abc/sysctl/etc/logmgt.acl -entry \
-add user:nogojoe:-
dcecp -c acl show /.:/subsys/ssp/abc/sysctl/etc/logmgt.acl -entry
{group:spsec-admin:c}
{group:sysctl-logmgt:at}
{user:nogojoe:-}
Sysctl creates only group entries in its DCE ACLs. See Types of DCE ACL entries for other types of DCE ACL entries that are supported.
The format of these ASCII text files is explained in the sysctl.acl section of the book PSSP: Command and Technical Reference.
Sysctl uses the following ACLs when the Kerberos V4 authentication method is in use:
This ACL file is installed with the product and initially contains no entries. You add entries for Kerberos V4 principals of persons you want to authorize according to your organizations security policy. If you do not give this level of authorization to at least one Kerberos V4 principal, the procedures that use the default ACL callback for authorization will not be available to anyone unless you redefine the callbacks by customizing the Sysctl configuration.
The supplied /etc/sysctl.acl file contains commented lines that are samples. Copy the sample lines and insert your own principal identifiers.
These ACL files might be initially empty or they might contain entries that are generated during installation and configuration of the relevant SP software component or licensed program. The authorization instructions for that component indicate how you can tailor these ACLs.
When you add entries to existing files or create your own, remember that the types of entries you need depends on which SP trusted service authentication methods the local server host is using.
The following is a sample Sysctl ACL file:
#acl# _principal sarah@TESTCELL.ABC.COM _principal joe - _acl_file /etc/mycmd.acl
This ACL includes entries for granting access to Kerberos V4 principal sarah and denying access to joe. The last entry names a file, that contains additional ACL entries.
The root user owns all Sysctl ACL files and is responsible for distributing the file to all nodes that share the same set of Sysctl resources. You can update an ACL file on multiple hosts in parallel using the Sysctl procedures for ACL file management. If you do not use those tools, you might want to use file collections to maintain configuration and ACL files. You can use the authenticated pcp command to securely copy files to multiple SP nodes. See Chapter 7, Managing file collections.
The /var/adm/SPlogs/sysctl/sysctld.log file is a logging file to which the Sysctl daemon (sysctld) writes. It logs the invocation of each Sysctl command. This is helpful for debugging. See the sysctld man page for information on specifying log file path names.