LOGINAPPL Class

selang Reference Guide › Classes and Properties › Classes in the AC Environment › LOGINAPPL Class

LOGINAPPL Class

Valid on UNIX

Each record in the LOGINAPPL class defines a login application, identifies who can use the program to log in, and controls the way the login program is used.

The key of the LOGINAPPL class record is the name of the application, that is, a logical name that represents a login application. This logical name is associated, in the LOGINPATH property, with the full path name of the executable.

CA ControlMinder can also control and protect generic login applications; this means that you can protect groups of login applications that match a certain rule with a generic pattern. To define a generic login application with selang, use the same commands as setting regular login restrictions, except the LOGINPATH parameter, which should include a generic path composed of a regular expression using one or more of the following characters: [, ], *, ?.

CA ControlMinder presets the property values for records in the LOGINAPPL class for standard login programs. You should list and verify the existing settings before making any changes.

Important! LOGINAPPL does not use the _default entry.

The following definitions describe the properties contained in this class record. Most properties are modifiable and can be manipulated using selang or the administration interfaces. Non-modifiable properties are marked informational.

ACL

Defines a list of accessors (users and groups) permitted to access the resource, and the accessors' access types.

Each element in the access control list (ACL) contains the following information:

Accessor: Defines an accessor.
Access: Defines the access authority that the accessor has to the resource.

Use the access parameter with the authorize or authorize- command to modify the ACL.

CALACL

Defines a list of the accessors (users and groups) that are permitted to access the resource, and their access types according to the Unicenter NSM calendar status.

Each element in the calendar access control list (CALACL) contains the following information:

Accessor: Defines an accessor.
Calendar: Defines a reference to a calendar in Unicenter TNG.
Access: Defines the access authority that the accessor has to the resource.

Access is permitted only when the calendar is ON. Access is denied in all other cases.

Use the calendar parameter with the authorize command to permit user or group access to the resource according to the access defined in the calendar ACL.

CALENDAR

Represents a Unicenter TNG calendar object for user, group, and resource restrictions in CA ControlMinder. CA ControlMinder fetches Unicenter TNG active calendars at specified time intervals.

COMMENT

Defines additional information that you want to include in the record. CA ControlMinder does not use this information for authorization.

Limit: 255 characters.

CREATE_TIME

(Informational) Displays the date and time when the record was created.

DAYTIME

Defines the day and time restrictions that govern when an accessor can access a resource.

Use the restrictions parameter with the chres, ch[x]usr, or ch[x]grp commands to modify this property.

The resolution of daytime restrictions is one minute.

LOGINFLAGS

Controls special features of the login application, including changes in device number and decrements to the grace logins number. Valid values are:

execlogin-Specifies that the login trigger is the first EXEC action that a process performs.
loginprefix-Specifies that CA ControlMinder adds the LOGINAPPL resource name as the prefix to the logged-in user name. For example, if you set this property and a user named user1 schedules a CRON task, when CA ControlMinder detects the CRON task login it sets the user name to USR_SBIN_CRON_user1.
Note: CA ControlMinder does not add the LOGINAPPL resource name as a prefix to root.
nograce-Indicates that grace logins should not be decremented when users log in through this application.
nograceroot-Indicates that grace logins should not be decremented when root logs in through this application.
nologin-Ensures that a login is entered for the user only. The login is not logged for parent programs.
A program like rlogin on some platforms causes rlogin to trigger the login and close the login sequence itself; this results in an actual login logged for root. After performing the login, rlogin forks to another program to perform the actual login.

This problem is apparent if you use a login program such as rlogin or telnet and run seaudit -a. You see that there are also login records for the same login with root as the uid.
pamlogin-Indicates that CA ControlMinder PAM login interception is used when users log in through this application.

Use the loginflags parameter with the chres, editres, or newres command to modify this property.

LOGINMETHOD

Indicates whether the login application is a pseudo login program for the purposes of CA ControlMinder protection. Valid values are:

normal-Indicates that this login application executes setuid and setgid calls itself. seosd checks the rules of the specified program.
pseudo-Indicates that this login application calls another program to execute setuid and setgid calls. seosd checks the rules on the other program.

Use the loginmethod parameter with the chres, editres, or newres command to modify this property.

Important! We recommend that you not modify this preset property.

LOGINPATH

The full path (or generic path) to the login application.

Use the loginpath parameter with the chres, editres, or newres command to modify this property.

LOGINSEQUENCE

Defines the sequence of seteuid, setuid, setgid, and setgroups events that seosd processes to set the user from the daemon starting the login process (usually inetd under root) to the user who is actually logged on. You can define up to eight system events.

The login interception sequence always starts with setgid or setgroups events, which are called triggers. It ends with a setuid event that changes the user's identity to the real user who logged in.

To successfully accomplish login, the program needs to perform all the specified processes in sequence starting with setgroups or setgid and ending with setuid or seteuid.

Setting the right LoginSequence for a program is a difficult task. Most login programs work well with the default SGRP,SUID setting; this setting means the program issues a setgroups system call and then a setuid command to change the user's identity to the target user.

However, if the SGRP, SUID setting does not work, you must use the following flags to specify the proper order:

SEID-First seteuid event
SUID-First setuid event
SGID-First setgid event
SGRP-First setgroup event
FEID-Second seteuid event
FUID-Second setuid event
FGID-Second setgid event
FGRP-Second setgroup event
N3EID-Third seteuid event
N3UID-Third setuid event
N3GID-Third setgid event
N3GRP-Third setgroup event

Important! You must use the flags to specify the correct login sequence. However, you can specify the flags in any order within the LOGINSEQUENCE parameter. For example, SGRP, SEID, FEID, N3EID is identical to N3EID, FEID, SGRP, SEID.

Note: If you do not know the sequence of system calls that the login program performs, you can view the trace and look for the setuid event that changed the user to the target uid, and then look at prior trace events starting with the first setgid or setgroups event.

For example, if you there is one setgroups event and then only the third setuid call sets the target user, you must set LOGINSEQUENCE to SGRP,SUID,FUID,N3UID. You can specify these flags in any order:

SETGRPS : P=565302 to 0,2,3,7,8,10,11,250,220,221,230

SUID  > P=565302 U=0    (R=0    E=0    S=0   ) to (R=0  E=0    S=0   ) () BYPASS
SUID  > P=565302 U=0    (R=0    E=0    S=0   ) to (R=0  E=0    S=-1  ) () BYPASS
LOGIN  : P=565302 User=target Terminal=mercury

The SETGRPS process indicates the trigger.
The first SUID command should be discounted because you can see that the root simply changed back to root, not the trigger user. (This is the SUID in the sequence.)
The second SUID command should be discounted as well because you can see that the root changed back to root, not the trigger user. (This is the FUID in the sequence.)
The LOGIN event is the actual SETUID event causing the login. (Because it is the third event, it is the N3UID flag in the sequence.)

Use the loginsequence parameter with the chres, editres, or newres command to modify this property.

NACL

The NACL property of a resource is an access control list that defines the accessors that are denied authorization to a resource, together with the type of access that they are denied (for example, write). See also ACL, CALACL, PACL. Each entry in the NACL contains the following information:

Accessor: Defines an accessor.
Access: Defines the type of access that is denied to the accessor.

Use the authorize deniedaccess command, or the authorize- deniedaccess- command, to modify this property.

NOTIFY

Defines the user to be notified when a resource or user generates an audit event. CA ControlMinder can email the audit record to the specified user.

Limit: 30 characters.

OWNER

Defines the user or group that owns the record.

RAUDIT

Defines the types of access events that CA ControlMinder records in the audit log. RAUDIT derives its name from Resource AUDIT. Valid values are:

all: All access requests.
success: Granted access requests.
failure: Denied access requests (default).
none: No access requests.

CA ControlMinder records events on each attempted access to a resource, and does not record whether the access rules were applied directly to the resource, or were applied to a group or class that had the resource as a member.

Use the audit parameter of the chres and chfile commands to modify the audit mode.

UACC

Defines the default access authority for the resource, which indicates the access granted to accessors who are not defined to CA ControlMinder or who do not appear in the ACL of the resource.

Use the defaccess parameter with the chres, editres, or newres command to modify this property.

UPDATE_TIME

(Informational) Displays the date and time when the record was last modified.

UPDATE_WHO

(Informational) Displays the administrator who performed the update.

WARNING

Specifies whether Warning mode is enabled. When Warning mode is enabled on a resource, all access requests to the resource are granted, and if an access request violates an access rule, a record is written to the audit log.