Security, autentication, and authorization
This chapter is dedicated to the latest security topics as they apply to AIX V7.1. Topics include:
8.1 Domain Role Based Access Control
The section discusses domain Role Based Access Control (RBAC).
This feature first became available in AIX V7.1 and is included in AIX 6.1 TL 06.
Domain RBAC is an enhancement to Enhanced Role Based Access Control, introduced in AIX V6.1.
8.1.1 The traditional approach to AIX security
The traditional approach to privileged administration in the AIX operating system has relied on a single system administrator account, named the root user.
The root user account is the superuser. It has the authority to perform all privileged system administration on the AIX system.
Using the root user, the administrator could perform day-to-day activities including, but not limited to, adding user accounts, setting user passwords, removing files, and maintaining system log files.
Reliance on a single superuser for all aspects of system administration raises issues with regard to the separation of administrative duties.
The root user allows the administrator to have a single point of administration when managing the AIX operating system, but in turn allows an individual to have unrestricted access to the operating system and its resources. While this freedom could be a benefit in day-to-day administration, it also has the potential to introduce security exposures.
While a single administrative account may be acceptable in certain business environments, some environments use multiple administrators, each with responsibility for performing different tasks.
Alternatively, in some environments, the superuser role is shared among two or more system administrators. This shared administrative approach may breach business audit guidelines in an environment that requires that all privileged system administration is attributable to a single individual.
Sharing administration functions may create issues from a security perspective.
With each administrator having access to the root user, there was no way to limit the operations that any given administrator could perform.
Since the root user is the most privileged user, the root user could perform operations and also be able to erase any audit log entries designed to keep track of these activities, thereby making the identification to an individual of the administrative actions impossible.
Additionally, if the access to the root user’s password were compromised and an unauthorized individual accesses the root user, then that individual could cause significant damage to the systems’ integrity.
Role Based Access Control offers the option to define roles to users to perform privileged commands based upon the user’s needs.
8.1.2 Enhanced and Legacy Role Based Access Control
In this section we discuss the differences between the two operating modes of RBAC available in AIX, Legacy mode and Enhanced mode.
The release of AIX V6.1 saw the introduction of an enhanced version of Role Based Access Control (RBAC), which added to the version of RBAC already available in AIX since V4.2.1.
To distinguish between the two versions, the following naming conventions are used:
Enhanced RBAC The enhanced version of RBAC introduced in AIX V6.1
Legacy RBAC The version of RBAC introduced in AIX V4.2.1
The following is a brief overview of Legacy RBAC and Enhanced RBAC.
For more information on Role Based Access Control, see AIX V6 Advanced Security Features Introduction and Configuration, SG24-7430 at:
Legacy RBAC
Legacy RBAC was introduced in AIX V4.2.1. The AIX security infrastructure began to provide the administrator with the ability to allow a user account other than the root user to perform certain privileged system administration tasks.
Legacy RBAC often requires that the command being controlled by an authorization have setuid to the root user in order for an authorized invoker to have the proper privileges to accomplish the operation.
The Legacy RBAC implementation introduced a predefined set of authorizations that can be used to determine access to administrative commands and could be expanded by the administrator.
Legacy RBAC includes a framework of administrative commands and interfaces to create roles, assign authorizations to roles, and assign roles to users.
The functionality of Legacy RBAC was limited because:
•The framework required changes to commands and applications for them to be RBAC enabled.
•The predefined authorizations were not granular.
•Users often required membership in a certain group as well as having a role with a given authorization in order to execute a command.
•A true separation of duties is difficult to implement. If a user account is assigned multiple roles, then all assigned roles are always active. There is no method to activate only a single role without activating all roles assigned to a user.
•The least privilege principle was not adopted in the operating system. Privileged commands must typically be setuid to the root user.
Enhanced RBAC
Beginning with AIX V6.1, Enhanced RBAC provides administrators with a method to delegate roles and responsibilities among one or more general user accounts.
These general user accounts may then perform tasks that would traditionally be performed by the root user or through the use of setuid or setgid.
The Enhanced RBAC integration options use granular privileges and authorizations and give the administrator the ability to configure any command on the system as a privileged command.
The administrator can use Enhanced RBAC to provide for a customized set of authorizations, roles, privileged commands, devices, and files through the Enhanced RBAC security database.
The Enhanced RBAC security database may reside either in the local file system or be managed remotely through LDAP.
Enhanced RBAC consists of the following security database files:
• Authorization Database
• Role Database
• Privileged Command Database
• Privileged Device Database
• Privileged File Database
Enhanced RBAC includes a granular set of system-defined authorizations and enables an administrator to create additional user-defined authorizations as necessary.
Both Legacy RBAC and Enhanced RBAC are supported on AIX V7.1.
Enhanced RBAC is enabled by default in AIX V7.1, but will not be active until the administrator configures the Enhanced RBAC functions.
Role Based Access Control may be configured to operate in either Legacy or Enhanced mode.
There is no specific install package in AIX V7.1 for Legacy or Enhanced mode RBAC because the majority of the Enhanced RBAC commands are included in the bos.rte.security fileset.
While Legacy RBAC is supported in AIX V7.1, administrators are encouraged to use Enhanced RBAC over Legacy RBAC.
Enhanced RBAC offers more granular control of authorizations and reduces the reliance upon setuid programs.
8.1.3 Domain Role Based Access Control
As discussed earlier, Enhanced RBAC provides administrators with a method to delegate roles and responsibilities to a non-root user, but Enhanced RBAC cannot provide the administrator with a mechanism to further limit those authorized users to specific system resources.
As an example, Enhanced RBAC could be used to authorize a non-root user to use the chfs command to extend the size of a JFS2 file system. After authorizing the non-root user, Enhanced RBAC could not limit the authorized non-root user to using the chfs command to extend only an individual or selected file system.
Domain RBAC introduces the domain into Role Based Access Control, a feature that allows the administrator to further restrict an authorized user to a specific resource.
With the introduction of Enhanced RBAC in AIX V6.1 the administrator was offered a granular approach to managing roles and responsibilities.
With the introduction of Domain RBAC, the granularity is further extended to allow finer control over resources.
Domain RBAC requires that Enhanced RBAC be enabled. Domain RBAC will not operate in the Legacy RBAC framework.
|
Note: Unless noted, further references to RBAC will refer to Enhanced RBAC, as Domain RBAC does not operate under Legacy RBAC.
|
Example 8-1 shows the lsattr command being used to determine whether Enhanced RBAC is enabled on an AIX V7.1 partition. The enhanced_RBAC true attribute shows that enhanced RBAC is enabled.
Example 8-1 Using the lsattr command to display the enhanced_RBAC status
# oslevel -s
7100-00-00-0000
# lsattr -El sys0 -a enhanced_RBAC
enhanced_RBAC true Enhanced RBAC Mode True
#
The enhanced_RBAC attribute may be enabled or disabled with the chdev command. If Enhanced RBAC is not enabled on your partition, it may be enabled by using the chdev command to change the sys0 device.
Example 8-2 shows the chdev command being used to change the enhanced_RBAC attribute from false to true.
Example 8-2 Using the chdev command to enable the enhanced_RBAC attribute
# lsattr -El sys0 -a enhanced_RBAC
enhanced_RBAC false Enhanced RBAC Mode True
# chdev -l sys0 -a enhanced_RBAC=true
sys0 changed
# lsattr -El sys0 -a enhanced_RBAC
enhanced_RBAC true Enhanced RBAC Mode True
# shutdown -Fr
SHUTDOWN PROGRAM
Thu Sep 16 11:00:50 EDT 2010
Stopping The LWI Nonstop Profile...
Stopped The LWI Nonstop Profile.
0513-044 The sshd Subsystem was requested to stop.
Wait for 'Rebooting...' before stopping.
Error reporting has stopped.
|
Note: Changing the enhanced_RBAC attribute will require a reboot of AIX for the change to take effect.
|
At the time of publication, Domain RBAC functionality is not available on Workload Partition (WPAR).
Domain RBAC definitions
Domain RBAC introduces new concepts into the RBAC security framework.
Subject A subject is defined as an entity that requires access to another entity. A subject is an initiator of an action. An example of a subject would be a process accessing a file. When the process accesses the file, the process is considered a subject. A user account may also be a subject when the user account has been granted association with a domain.
Object An object is an entity that holds information that can be accessed by another entity. The object is typically accessed by a subject and is typically the target of the action. The object may be thought of as the entity on which the action is being performed. As an example, when process 2001 tries to access another process, 2011, to send a signal then process 2001 is the subject and process 2011 is the object.
Domain A domain is defined as a category to which an entity may belong. When an entity belongs to a domain, access control to the entity is governed by a rule set that is known as a property. An entity could belong to more than one domain at a time. Each domain has a unique numeric domain identifier. A maximum of 1024 domains are allowed, with the highest possible value of the domain identifier allowed as the number 1024. A user account may belong to a domain. When a user account belongs to a domain, it can be described as having an association with a domain.
Property A property is the rule set that determines whether a subject is granted access to an object.
Conflict Set A conflict set is a domain object attribute that restricts access to a domain based upon the existing domain access that an entity may already have defined. This is further explained when discussing the setsecattr command, later in this section.
Security Flag A security flag is a domain object attribute that may restrict access to an object based upon the FSF_DOM_ANY or FSF_DOM ALL attribute. When the secflags attribute is set to FSF_DOM_ANY a subject may access the object when it is associated with any of the domains specified in the domains attribute. When the secflags attribute is FSF_DOM_ALL, a subject may access the object only when it is associated with all of the domains specified in the attribute. The default secflags value is FSF_DOM_ALL. If no secflags attribute value is specified, then the default value of FSF_DOM_ALL is used.
In Example 8-3 we see the ps command being used to display the process identifier assigned to the vi command. The vi command is being used by the root user to edit a file named /tmp/myfile.
Example 8-3 Using the ps command to identify the process editing /tmp/myfile
# cd /tmp
# pwd
/tmp
# ls -ltra myfile
-rw-r--r-- 1 root system 15 Sep 02 11:58 myfile
# ps -ef|grep myfile
root 6226020 6488264 0 11:59:42 pts/1 0:00 vi myfile
# ps -fT 6226020
UID PID PPID C STIME TTY TIME CMD
root 6226020 6488264 0 11:59:42 pts/1 0:00 vi myfile
#
In Example 8-3 we see an example of the subject and the object.
•The subject is process id 6226020, which is a process that is executing the vi command to edit the file named /tmp/myfile.
•The object is the file named /tmp/myfile.
8.1.4 Domain RBAC command structure
Domain RBAC introduces four new commands into the RBAC framework.
These are the mkdom, lsdom, chdom and rmdom commands.
The mkdom command
The mkdom command creates a new RBAC domain.
The syntax of the mkdom command is:
mkdom [ Attribute = Value ...] Name
The mkdom command creates a new domain in the domain database. The domain attributes can be set during the domain creation phase by using the Attribute = Value parameter.
The domain database is located in the /etc/security/domains file.
The mkdom command has the following requirements:
•The system must be operating in the Enhanced Role Based Access Control (RBAC) mode.
•Modifications made to the domain database are not available for use until updated into the Kernel Security Tables (KST) with the setkst command.
•The mkdom command is a privileged command. Users of this command must have activated a role with the aix.security.domains.create authorization or be the root user.
Example 8-4 shows the mkdom command being used by the root user to create a new domain named Network with a domain identifier (Domain ID) of 22:
Example 8-4 Using the mkdom command to create the domain Network with a Domain ID of 22
# mkdom id=22 Network
# lsdom Network
Network id=22
#
|
Note: The mkdom command will not return with text output when a domain is successfully created. The lsdom command was used in Example 8-4 to display that the mkdom command did successfully create the Network domain. The lsdom command is introduced next.
|
The mkdom command contains character usage restrictions. For a full listing of these character restrictions, see the mkdom command reference.
The lsdom command
The lsdom command displays the domain attributes of an RBAC domain.
The domain database is located in the /etc/security/domains file.
The syntax of the lsdom command is:
lsdom [ -C] [ -f] [ -a Attr [Attr]... ] { ALL | Name [ , Name] ...}
The lsdom command lists the attributes of either all domains or specific domains.
The lsdom command lists all domain attributes. To view selected attributes, use the lsdom -a command option.
The lsdom command can list the domain attributes in the following formats:
•List domain attributes on one line with the attribute information displayed as Attribute = Value, each separated by a blank space. This is the default list option.
•To list the domain attributes in stanza format, use the lsdom -f command flag.
•To list the information as colon-separated records, use the lsdom -C command flag.
The lsdom command has the following domain name specification available:
ALL Indicates that all domains will be listed, including the domain attributes.
Name Indicates the name of the domain that will have the attributes listed. This may be multiple domain names, comma separated.
The lsdom command has the following requirements:
•The system must be operating in the Enhanced Role Based Access Control (RBAC) mode.
•The lsdom command is a privileged command. Users of this command must have activated a role with the aix.security.domains.list authorization or be the root user.
Example 8-5 shows the lsdom -f command being used by the root user to display the DBA and HR domains in stanza format.
Example 8-5 Using the lsdom command -f to display the DBA and HR domains in stanza format
# lsdom -f DBA,HR
DBA:
id=1
HR:
id=2
#
The chdom command
The chdom command modifies attributes of an existing RBAC domain.
The syntax of the chdom command is:
chdom Attribute = Value ... Name
If the specified attribute or attribute value is invalid, the chdom command does not modify the domain.
The chdom command has the following requirements:
•The system must be operating in Enhanced Role Based Access Control (RBAC) mode.
•Modifications made to the domain database are not available for use until updated into the Kernel Security Tables with the setkst command.
•The chdom command is a privileged command. Users of this command must have activated a role with the aix.security.dom.change authorization or be the root user.
Example 8-6 shows the chdom command being used by the root user to change the ID of the Network domain from 22 to 20. The Network domain was created in Example 8-4 on page 297 and has not yet been used and is not associated with any entities.
Example 8-6 Using the chdom command to change the ID attribute of the Network domain
# lsdom -f Network
Network:
id=22
# chdom id=20 Network
# lsdom -f Network
Network:
id=20
#
|
Note: Modification of the ID attribute of a domain can affect the security aspects of the system, as processes and files might be using the current value of the ID.
Modify the ID of a domain only if the domain has not been used, else the security aspects of the system could be adversly effected.
|
The rmdom command
The rmdom command removes an RBAC domain.
The syntax of the rmdom command is:
rmdom Name
The rmdom command removes the domain that is identified by the Name parameter. It only removes the existing domains from the domain database.
A domain that is referenced by the domain object database cannot be removed until you remove the references to the domain.
The rmdom command has the following requirements:
•The system must be operating in Enhanced Role Based Access COntrol (RBAC) mode.
•Modifications made to the domain database are not available for use until updated into the Kernel Security Tables with the setkst command.
•The rmdom command is a privileged command. Users of this command must have activated a role with the aix.security.dom.remove authorization or be the root user.
Example 8-7 shows the rmdom command being used by the root user to remove the Network domain. The Network domain has not yet been used and is not with any entities.
By using the lssecattr -o ALL command, we can see that there are no domain objects referenced by the Network domain, so the Network domain may be removed.
Example 8-7 Using the rmdom command to remove the Network domain
# lsdom -f Network
Network:
id=22
# lssecattr -o ALL
/home/dba/privatefiles domains=DBA conflictsets=HR objtype=file secflags=FSF_DOM_ANY
# rmdom Network
# lsdom -f Network
3004-733 Role "Network" does not exist.
# lsdom ALL
DBA id=1
HR id=2
#
|
Note: If a user account belonged to the Network domain, the user account would still see the domains=Network attribute listed from the lsuser output. This domains=Network attribute value can be removed with the chuser command.
|
In addition to the mkdom, lsdom, chdom, and rmdom commands, domain RBAC introduces enhanced functionality to the existing commands, shown in Table 8-1.
Table 8-1 Domain RBAC enhancements to existing commands
|
Command
|
Description
|
New Functionality
|
|
setsecattr
|
Add or modify the domain attributes for objects
|
-o
|
|
lssecattr
|
Display the domain attributes for objects
|
-o
|
|
rmsecattr
|
Remove domain object definitions
|
-o
|
|
setkst
|
Read the security databases and load the information from the databases into the kernel security tables
|
The option to download the domain and the domain object databases
|
|
lsuser
|
List user attributes
|
The attribute domain is added for users
|
|
lssec
|
List user attributes
|
The attribute domain is added for users
|
|
chuser
|
Change user attributes
|
The attribute domain is added for users
|
|
chsec
|
Change user attributes
|
The attribute domain is added for users
|
The Domain RBAC enhanced functionality to the commands in Table 8-1 is further explained in the following examples.
The setsecattr command
The setsecattr command includes the -o flag. It is used to add and modify domain attributes for objects. An example of the setsecattr command is shown in Example 8-8.
Example 8-8 The setsecatrr -o command
# setsecattr -o domains=DBA conflictsets=HR objtype=file
secflags=FSF_DOM_ANY /home/dba/privatefiles
secflags=FSF_DOM_ANY /home/dba/privatefiles
#
As discussed earlier, domain RBAC introduces the conflict set and security flag object attributes into the RBAC framework.
The conflict set attribute can deny access to an object based upon existing domain association. When used, the conflictsets attribute would be set to a domain name other than the domain defined in the domains attribute.
In Example 8-8 the conflictsets attribute is defined as HR and the domains attribute as DBA. Both HR and DBA are names of domains defined in the RBAC security database.
Using the conflictsets attribute in this manner will restrict access to the /home/dba/privatefiles object by entities that have an association with the HR domain, regardless of whether these entities have membership to the DBA domain.
Example 8-9 shows the lssecattr and the ls -ltra commands being used to display the attributes of the file named /home/dba/privatefiles.
Example 8-9 Using the lssecattr and ls -ltra command to display the file named /home/dba/privatefiles
# cd /home/dba
# lssecattr -o privatefiles
/home/dba/privatefiles domains=DBA conflictsets=HR
objtype=file secflags=FSF_DOM_ANY
objtype=file secflags=FSF_DOM_ANY
# ls -ltra /home/dba/privatefiles
-rw-r--r-- 1 dba staff 33 Sep 03 11:18 privatefiles
# lssec -f /etc/security/user -s dba -a domains
dba domains=DBA
# lssecattr -o /home/dba/example111
"/home/dba/example111" does not exist in the domained object database.
#
From the output in Example 8-9 we can determine that:
•The lssecattr command shows that the file named /home/dba/privatefiles is defined as a domain RBAC object. If the file was not defined as a domain RBAC object, the output returned would be similar to the response from the lssecattr -o /home/dba/example111 command which returned "/home/dba/example111" does not exist in the domained object database.
•The lssecattr command shows that the domains attribute is defined as the DBA domain and the conflictsets attribute is defined as the HR domain.
•The lssecattr command shows secflags=FSF_DOM_ANY. In this example, FSF_DOM_ANY does not offer any further restriction because the domain RBAC object /home/dba/privatefiles is defined with only a single domain.
•The ls -ltra command shows that the dba user account has read and write access to the file named /home/dba/privatefiles through Discretionary Access Control (DAC).
•The lssec command shows that the dba user account has been granted association to the DBA domain but has not been granted association to the HR domain, because only the DBA domain is returned in the domains=DBA listing.
By using the combination of conflictsets and domains in Example 8-9 on page 302 the dba user account would be able to access the file named /home/dba/privatefiles.
If the dba user account was to be granted association to the HR domain, then the dba user account would no longer be able to access the file named /home/dba/privatefiles because the HR domain is defined as a conflict set to the domain RBAC object /home/dba/privatefiles.
The access to the file named /home/dba/privatefiles would be refused even though the dba user has read and write access to the file via DAC.
The secflags=FSF_DOM_ANY attribute sets the behavior of the domains attribute of the object. In Example 8-9 on page 302 the object /home/dba/privatefiles is defined with only the DBA domain.
If the object /home/dba/privatefiles had been defined to multiple domains, and the secflags attribute been set as FSF_DOM_ALL, then the dba user account would have to be associated with all domains defined in the domains attribute for the /home/dba/privatefiles object, else access to the /home/dba/privatefiles would be denied.
The lssecattr command
The lssecattr command now includes the -o flag. It is used to display the domain attributes for objects. An example of the lssecattr command is shown in Example 8-10.
Example 8-10 The lssecattr -o command
# lssecattr -o /home/dba/privatefiles
/home/dba/privatefiles domains=DBA conflictsets=HR objtype=file
secflags=FSF_DOM_ANY
secflags=FSF_DOM_ANY
#
The rmsecattr command
The rmsecattr command now includes the -o flag. It is used to remove domain object definitions from the RBAC security database. An example of the rmsecattr command is shown in Example 8-11.
Example 8-11 The rmsecattr -o command
# rmsecattr -o /home/dba/privatefiles
#
The setkst command
The setkst command is used to read the security database and load the security databases into the kernel security tables (KST).
It includes the option to load the domain and the domain object database.
The domain and domain object database are located in the /etc/security directory in the following files:
The domains file The domain security database. To update the domain security database into the KST, use the setkst -t dom command.
The domobj file The domain object security database. To update the domain object security database into the KST, use the setkst -t domobj command.
An example of the setkst command is shown in Example 8-12.
Example 8-12 The setkst -t command updating the domain into the KST
# setkst -t dom
Successfully updated the Kernel Domains Table.
#
|
Note: Changes made to the RBAC database are not activated into the Kernel Security Table (KST) until such time as the setkst command is executed.
|
The lskst command
The lskst command lists the entries in the Kernel Security Tables (KST). It includes the option to list the domain and the domain object database.
An example of the lskst command is shown in Example 8-13.
Example 8-13 Listing the kernel security tables with the lskst -t command
# lskst -t domobj
/home/dba/privatefiles objtype=FILE domains=DBA
conflictsets=HR secflags=FSF_DOM_ANY
conflictsets=HR secflags=FSF_DOM_ANY
#
The lsuser command
The lsuser command includes the option to display the domains to which a user has association. An example of the lsuser command is shown in Example 8-14.
Example 8-14 The lsuser -a command - display a user domain access
# lsuser -a domains dba
dba domains=DBA
#
The lssec command
As with the lsuser command, the lssec command includes the option to display the domains to which a user has an association. An example of the lssec command is shown in Example 8-15.
Example 8-15 The lssec -f command - display a user domain access
# lssec -f /etc/security/user -s dba -a domains
dba domains=DBA
#
The chuser command
The chuser command includes the option to change the domains to which a user has an association. An example of the chuser command is shown in Example 8-16.
Example 8-16 The chuser command - change a user domain association
# lsuser -a domains dba
dba domains=DBA
# chuser domains=HR dba
# lsuser -a domains dba
dba domains=HR
#
To remove all domains to which a user has an association, the chuser command can be used without any domain attribute, as shown in Example 8-17.
Example 8-17 The chuser command - remove all domain association from a user
# lsuser -a domains dba
dba domains=HR
# chuser domains= dba
# lsuser -a domains dba
dba
# lssec -f /etc/security/user -s dba -a domains
dba domains=
#
The chsec command
As with the chuser command, the chsec command includes the option to change the domains to which a user has an association. An example of the chsec command is shown in Example 8-18.
Example 8-18 The chsec command - adding DBA domain access to the dba user
# lssec -f /etc/security/user -s dba -a domains
dba domains=
# chsec -f /etc/security/user -s dba -a domains=DBA
# lssec -f /etc/security/user -s dba -a domains
dba domains=DBA
#
8.1.5 LDAP support in Domain RBAC
The Enhanced RBAC security database may reside either in the local file system or be managed remotely through LDAP.
At the time of publication the domain RBAC databases must reside locally in the /etc/security directory.
When upgrading an LPAR that is using RBAC with LDAP authentication, the LDAP authentication will remain operational. Any domain RBAC definitions will reside locally in the /etc/security directory.
The /etc/nscontrol.conf file contains the location and lookup order for the RBAC security database.
Example 8-19 shows the RBAC security database stanza output of the /etc/nscontrol.conf file.
The secorder attribute describes the location of the security database file. It is possible to store the Enhanced RBAC security database files either in the /etc/security directory or on an LDAP server, or a combination of the two.
Domain RBAC security database files are only stored in the /etc/security directory, so they will not have a stanza in the /etc/nscontrol.conf file.
The options for the secorder attribute are:
files The database file is located in the /etc/security directory. This is the default location.
LDAP The database file is located on an LDAP server.
LDAP, files The database file is located on the LDAP server and the /etc/security directory. The lookup order is LDAP first, followed by the /etc/security directory
files, LDAP The database file is located in the /etc/security directory and the LDAP server. The lookup order is the /etc/security directory first, followed by the LDAP server.
Example 8-19 The /etc/nscontrol.conf file
# more /etc/nscontrol.conf
# IBM_PROLOG_BEGIN_TAG
# This is an automatically generated prolog.
#
output ommitted .....
#
authorizations:
secorder = files
roles:
secorder = files
privcmds:
secorder = files
privdevs:
secorder = files
privfiles:
secorder = files
#
Example 8-19 on page 307 shows that the five files in the Enhanced RBAC security database are stored in the /etc/security directory and LDAP is not being used for RBAC on this server.
8.1.6 Scenarios
This section introduces four scenarios to describe the usage of the new features available in domain RBAC.
The four scenarios consist of:
Device scenario Using domain RBAC to control privileged command execution on logical volume devices.
File scenario Two scenarios. Using domain RBAC to restrict user access and to remove user access to a file.
Network scenario Use domain RBAC to restrict privileged access to a network interface.
These four scenarios show examples of how domain RBAC may be used to provide additional functionality to the AIX security framework.
The AIX partition used in the scenario:
•Has AIX V7.1 installed.
•Is operating in Enhanced_RBAC mode.
•Has no additional or customized RBAC roles or authorizations defined.
•Has no previous domain RBAC customizing defined.
|
Note: At the time of publication, Domain RBAC may be managed through the command line only. Domain RBAC support is not included in the System Management Interface Tool (SMIT).
|
Device scenario
Domain RBAC allows the administrator to define devices as domain RBAC objects.
In this scenario, logical volume devices will be defined as domain RBAC objects.
The AIX V7.1 LPAR consists of two volume groups, rootvg and appsvg.
The appsvg group contains application data, which is supported by the application support team by using the appuser user account.
The application support team has requested the ability to add/modify and delete the four file systems used by the application.
The application file systems reside exclusively in a volume group named appsvg.
The systems administrator will grant the application support team the ability to add/modify/delete the four application file systems in the appsvg volume group, but restrict add/modify/delete access to all other file systems on the LPAR.
Enhanced RBAC allows the systems administrator to grant the application support team the privileges to add/modify/delete the four file systems without having to grant access to the root user.
Enhanced RBAC does not allow the systems administrator to restrict access to only those four file systems needed by the application support team.
Domain RBAC will allow such a granular separation of devices and allow the systems administrator to allow add/modify/delete access to only the four application file systems and restrict add/modify/delete access to the remaining file systems.
The system administrator identifies that the application support team requires access to the following AIX privileged commands.
crfs Create a new file system
chfs Modify an existing file system
rmfs Remove an existing file system
mount Mount a file systems
unmount Unmount a file system
With the privileged commands identified, the administrator defines an RBAC role to allow the application support team to perform these five privileged commands.
Unless noted otherwise, all commands in the scenario will be run as the root user.
AIX includes predefined RBAC roles, one of which is the FSAdmin role. The FSAdmin role includes commands that may be used to manage file systems and could be used in this situation.
In this scenario the administrator creates a new RBAC role, named apps_fs_manage, using the mkrole command.
The benefits in creating the apps_fs_manage role are:
•This introduces an example of using the mkrole command used in Enhanced RBAC.
•The apps_fs_manage role includes only a subset of the privileged commands included in the FSAdmin role. This complies with the Least Privilege Principal.
Before using the mkrole command to create the apps_fs_manage role, the administrator must determine the access authorizations required by each of the commands that will be included in the apps_fs_manage role.
The lssecattr command is used to determine the access authorizations.
Example 8-20 shows the lssecattr command being used to determine the access authorizations of each of the five privileged commands that will be included in the apps_fs_manage role.
Example 8-20 Using the lssecattr command to identify command authorizations
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# lssecattr -c -a accessauths /usr/sbin/crfs
/usr/sbin/crfs accessauths=aix.fs.manage.create
# lssecattr -c -a accessauths /usr/sbin/chfs
/usr/sbin/chfs accessauths=aix.fs.manage.change
# lssecattr -c -a accessauths /usr/sbin/rmfs
/usr/sbin/rmfs accessauths=aix.fs.manage.remove
# lssecattr -c -a accessauths /usr/sbin/mount
/usr/sbin/mount accessauths=aix.fs.manage.mount
# lssecattr -c -a accessauths /usr/sbin/umount
/usr/sbin/umount accessauths=aix.fs.manage.unmount
#
Example 8-20 shows that the privileged commands require the following access authorizations:
crfs Requires the access authorization aix.fs.manage.create.
chfs Requires the access authorization aix.fs.manage.change.
rmfs Requires the access authorization aix.fs.manage.remove.
mount Requires the access authorization aix.fs.manage.mount.
unmount Requires the access authorization aix.fs.manage.unmount.
At this stage, the administrator has identified the privileged commands required by the application support team, decided on the name of the RBAC role to be created, and determined the access authorizations required for the five privileged commands.
The administrator may now create the apps_fs_manage RBAC role with the mkrole command.
Example 8-21 Using the mkrole command - create the apps_fs_manage role
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# mkrole authorizations=aix.fs.manage.create,aix.fs.manage.change,/
aix.fs.manage.remove,/aix.fs.manage.mount,aix.fs.manage.unmount/ dfltmsg='Manage apps filesystems' apps_fs_manage
aix.fs.manage.remove,/aix.fs.manage.mount,aix.fs.manage.unmount/ dfltmsg='Manage apps filesystems' apps_fs_manage
# lsrole apps_fs_manage
apps_fs_manage authorizations=aix.fs.manage.create,aix.fs.manage.change,/
aix.fs.manage.remove,aix.fs.manage.mount,aix.fs.manage.unmount rolelist= groups= visibility=1 screens=* dfltmsg=Manage apps filesystems msgcat= auth_mode=INVOKER id=11
aix.fs.manage.remove,aix.fs.manage.mount,aix.fs.manage.unmount rolelist= groups= visibility=1 screens=* dfltmsg=Manage apps filesystems msgcat= auth_mode=INVOKER id=11
#
|
Note: The smitty mkrole fastpath may also be used to create an RBAC role. Due to the length of the authorization definitions, using the smitty mkrole fastpath may be convenient when multiple access authorizations are included in a role.
|
Once the apps_fs_manage role has been created, the role must be updated into the Kernel Security Tables (KST) with the setkst command. The role is not available for use until the setkst command updates the changes into the KST.
The lsrole command output shows that the apps_fs_manage role exists in the RBAC database, but when the swrole command is used to switch to the role, the role switching is not allowed.
This is because the apps_fs_manage role has not been updated into the KST.
The administrator can verify this by using the lskst command.
The lskst command lists the KST, whereas the lsrole command lists the contents of the RBAC security database in the /etc/security directory.
Example 8-22 Using the lsrole, swrole, and lskst commands
# lsrole apps_fs_manage
apps_fs_manage authorizations=aix.fs.manage.create,aix.fs.manage.change,/
aix.fs.manage.remove,aix.fs.manage.mount,aix.fs.manage.unmount rolelist= groups= visibility=1 screens=* dfltmsg=Manage apps filesystems msgcat= auth_mode=INVOKER id=11
aix.fs.manage.remove,aix.fs.manage.mount,aix.fs.manage.unmount rolelist= groups= visibility=1 screens=* dfltmsg=Manage apps filesystems msgcat= auth_mode=INVOKER id=11
# swrole apps_fs_manage
swrole: 1420-050 apps_fs_manage is not a valid role.
# lskst -t role apps_fs_manage
3004-733 Role "apps_fs_manage" does not exist.
#
In Example 8-23 we use the setkst command to update the KST with the changes made to the RBAC security database.
The setkst command may be run without any options or with the setkst -t option.
The setkst -t command allows the KST to be updated with only a selected RBAC database table or tables.
Example 8-23 shows the setkst -t command being used to update the KST with only the RBAC role database information.
Example 8-23 The setkst -t command - updating the role database into the KST
# lskst -t role apps_fs_manage
3004-733 Role "apps_fs_manage" does not exist.
# setkst -t role
Successfully updated the Kernel Role Table.
# lskst -t role -f apps_fs_manage
apps_fs_manage:
authorizations=aix.fs.manage.change,aix.fs.manage.create,aix.fs.manage.mount,/
aix.fs.manage.remove,aix.fs.manage.unmount
aix.fs.manage.remove,aix.fs.manage.unmount
rolelist=
groups=
visibility=1
screens=*
dfltmsg=Manage apps filesystems
msgcat=
auth_mode=INVOKER
id=11
#
After updating the KST, the appuser account must be associated with the apps_fs_manage role.
Use the lsuser command to display whether any roles have previously been associated with the appuser account.
In this case, the appuser account has no role associations defined, as can be seen from the lsuser command output in Example 8-24.
If the appuser account had existing roles associated, the existing roles would need to be included in the chuser command along with the new apps_fs_manage role.
The chuser command is used in Example 8-24 to associate the appuser account with the apps_fs_manage role.
Example 8-24 The lsuser and chuser commands - assigning the apps_fs_manage role to the appuser account with the chuser command
# lsuser -a roles appuser
appuser roles=
# chuser roles=apps_fs_manage appuser
# lsuser -a roles appuser
appuser roles=apps_fs_manage
#
At this stage, the administrator has completed the steps required to grant the appuser account the ability to use the crfs, chfs, rmfs, mount and unmount commands. Even though these privileged commands could normally only be executed by the root user, the RBAC framework allows a non-privileged user to execute these commands, once the appropriate access authorizations and roles have been created and associated.
To demonstrate this, the appuser account uses the chfs and umount commands.
Example 8-25 shows the appuser account login and uses the rolelist command to display to which RBAC roles it has an association with and whether the role is effective.
A role that is active on the user account is known as the effective role.
Example 8-25 Using the rolelist -a and rolelist -e commands
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ rolelist -a
apps_fs_manage aix.fs.manage.change
aix.fs.manage.create
aix.fs.manage.mount
aix.fs.manage.remove
aix.fs.manage.unmount
$ rolelist -e
rolelist: 1420-062 There is no active role set.
$
From the rolelist -a and rolelist -e output you can determine that the appuser has been associated with the apps_fs_manage role, but the role is not currently the effective role.
Use the swrole command to switch to the apps_fs_manage role.
Once the swrole command is used to switch to the apps_fs_manage role, the role becomes the effective role, allowing the appuser account to perform the privileged commands defined in the apps_fs_manage role.
Example 8-26 shows the appuser account using the swrole command to switch to the apps_fs_manage role.
Example 8-26 The appuser account using the swrole command to switch to the apps_fs_manage role
$ ps
PID TTY TIME CMD
7995462 pts/0 0:00 -ksh
9633860 pts/0 0:00 ps
$ swrole apps_fs_manage
appuser's Password:
$ rolelist -e
apps_fs_manage Manage apps filesystems
$ ps
PID TTY TIME CMD
7995462 pts/0 0:00 -ksh
9044098 pts/0 0:00 ps
9240642 pts/0 0:00 ksh
$
|
Note: The swrole command requires authentication with the user’s password credentials.
The swrole command initiates a new shell, which can be seen with the new PID 940642, displayed in the ps command output.
|
The appuser account may now execute the privileged commands in the apps_fs_manage role.
Example 8-27 The appuser account using the chfs command to add 1 GB to the /apps04 file system
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ df -g /apps04
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/appslv_04 1.25 0.18 86% 15 1% /apps04
$ chfs -a size=+1G /apps04
Filesystem size changed to 4718592
$ df -g /apps04
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/appslv_04 2.25 1.18 48% 15 1% /apps04
$
The appuser was successful in using the chfs command to add 1 GB to the /apps04 file system.
The RBAC role allows the appuser account to execute the chfs command. This is the expected operation of the RBAC role.
Example 8-28 The appuser account using the umount command to unmount the /apps01 file system
$ df -g /apps01
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/appslv_01 1.25 0.18 86% 15 1% /apps01
$ unmount /apps01
$ df -g /apps01
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/hd4 0.19 0.01 95% 9845 77% /
$lslv appslv_01
LOGICAL VOLUME: appslv_01 VOLUME GROUP: appsvg
LV IDENTIFIER: 00f61aa600004c000000012aee536a63.1 PERMISSION: read/write
VG STATE: active/complete LV STATE: closed/syncd
TYPE: jfs2 WRITE VERIFY: off
MAX LPs: 512 PP SIZE: 64 megabyte(s)
COPIES: 1 SCHED POLICY: parallel
LPs: 36 PPs: 36
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: minimum RELOCATABLE: yes
INTRA-POLICY: middle UPPER BOUND: 32
MOUNT POINT: /apps01 LABEL: /apps01
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: NO
$
In Example 8-28, the appuser was successfully able to use the unmount command to unmount the /apps01 file system. By using the df and the lslv commands, we can determine that the /apps01 file system has been unmounted.
The RBAC role is allowing the appuser account to execute the unmount command. This is the expected operation of the RBAC role.
By using RBAC, the administrator has been able to grant the appuser account access to selected privileged commands. This has satisfied the request requirements of the application support team, because the appuser may now manage the four file systems in the appsvg.
Prior to domain RBAC, there was no RBAC functionality to allow the administrator to grant a user privileged access to only selected devices. For example, if privileged access was granted to the chfs command, the privilege could be used to change the attributes of all file systems.
This meant that there was no way to prevent a user-granted privileged access to the chfs command from accessing or modifying file systems to which they may not be authorized to access or administer.
The /backup file system was not a file system to which the appuser account requires privileged access, but because the appuser account has been granted privileged access to the chfs command, the administrator is unable to use Enhanced RBAC to limit the file systems that the appuser may modify.
In Example 8-29 we see the appuser account using the chfs command to add 1 GB to the /backup file system.
Example 8-29 The appuser account using the chfs command to change the /backup file system
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ df -g /backup
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/backup_lv 1.25 1.15 8% 5 1% /backup
$ chfs -a size=+1G /backup
Filesystem size changed to 4718592
$ df -g /backup
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/backup_lv 2.25 2.15 5% 5 1% /backup
$
The appuser account was able to modify the /backup file system because the apps_fs_manage role includes the access authorization for the chfs command.
The RBAC role is functioning correctly, but does not offer the functionality to limit the chfs command execution to only selected file systems.
Domain RBAC introduces the domain into Role Based Access Control.
The domain allows the administrator to further granualize the privileged command execution by limiting access to system resources to which a user may be granted privileged command execution.
The administrator will now use domain RBAC to:
1. Create two RBAC domains
2. Create multiple domain RBAC objects
3. Update the Kernel Security Tables (KST)
4. Associate the RBAC domain to the appuser account
5. Attempt to use the chlv command to change the /apps04 and /backup file systems
Firstly, the administrator creates two RBAC domains:
applvDom This domain will be used to reference the /apps01, /apps02, /apps03 and /apps04 file systems.
privlvDom This domain will be used to restrict access to the file systems that the appuser may access.
|
Note: RBAC domain names do have to be in mixed case. Mixed case has been used in this scenario as an example.
|
Example 8-30 shows the mkdom command being used by the root user to create the applvDom and privlvDom domains.
Example 8-30 The mkdom command - creating the applvDom and privlvDom domains
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# mkdom applvDom
# lsdom applvDom
applvDom id=1
# mkdom privlvDom
# lsdom privlvDom
privlvDom id=2
#
The next step is to define the file systems as domain RBAC objects.
The setsecattr command is used to define domain RBAC objects. In this scenario the administrator wishes to grant privileged access to four file systems and restrict privileged access to the remaining file systems. To do this the administrator needs to define each file system as a domain RBAC object.
The administrator ensures that all file systems on the server are mounted, then uses the df command to check the logical volume and file system names.
Example 8-31 The df -kP output - file systems on the AIX V7.1 LPAR
# df -kP
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hd4 196608 186300 10308 95% /
/dev/hd2 2031616 1806452 225164 89% /usr
/dev/hd9var 393216 335268 57948 86% /var
/dev/hd3 131072 2184 128888 2% /tmp
/dev/hd1 65536 428 65108 1% /home
/dev/hd11admin 131072 380 130692 1% /admin
/proc - - - - /proc
/dev/hd10opt 393216 179492 213724 46% /opt
/dev/livedump 262144 368 261776 1% /var/adm/ras/livedump
/dev/backup_lv 2359296 102272 2257024 5% /backup
/dev/appslv_01 1310720 1117912 192808 86% /apps01
/dev/appslv_02 1310720 1117912 192808 86% /apps02
/dev/appslv_03 1310720 1117912 192808 86% /apps03
/dev/appslv_04 2359296 1118072 1241224 48% /apps04
#
The administrator now uses the setsecattr command to define each of the four application file systems as domain RBAC objects.
Example 8-32 shows the setsecattr command being used by the root user to define the domain RBAC objects for the four appsvg file systems.
|
Note: When defining a file system object in domain RBAC, the logical volume device name will be used for the domain object.
|
Example 8-32 Using the setsecattr command to define the four application file systems as domain RBAC objects
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# setsecattr -o domains=applvDom objtype=device secflags=FSF_DOM_ANY /dev/appslv_01
# setsecattr -o domains=applvDom objtype=device secflags=FSF_DOM_ANY /dev/appslv_02
# setsecattr -o domains=applvDom objtype=device secflags=FSF_DOM_ANY /dev/appslv_03
# setsecattr -o domains=applvDom objtype=device secflags=FSF_DOM_ANY /dev/appslv_04
# lssecattr -o /dev/appslv_01
/dev/appslv_01 domains=applvDom objtype=device secflags=FSF_DOM_ANY
# lssecattr -o /dev/appslv_02
/dev/appslv_02 domains=applvDom objtype=device secflags=FSF_DOM_ANY
# lssecattr -o /dev/appslv_03
/dev/appslv_03 domains=applvDom objtype=device secflags=FSF_DOM_ANY
# lssecattr -o /dev/appslv_04
/dev/appslv_04 domains=applvDom objtype=device secflags=FSF_DOM_ANY
#
In Example 8-32 the following attributes were defined
Domain The domains attribute is the domain to which the domain RBAC object will be associated.
Object Type This is the type of domain RBAC object. The objtype=device is used for a logical volume.
Security Flags When the secflags attribute is set to FSF_DOM_ANY a subject may access the object when it contains any of the domains specified in the domains attribute.
Device Name This is the full path name to the logical volume corresponding to the file system. As an example, /dev/appslv_01 is the logical volume corresponding to the /apps01 file system.
|
Note: In domain RBAC, all objects with an objtype=device must specify the full path name to the device, starting with the /dev name.
As an example, the rootvg volume group device would be specified to domain RBAC as objtype=/dev/rootvg.
|
The administrator will now use the setsecattr command to define the remaining file systems as domain RBAC objects.
Example 8-33 shows the setsecattr command being used by the root user to define the domain RBAC objects for the remaining file systems.
Example 8-33 Using the setsecattr command to define the remaining file systems as domain RBAC objects
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/hd4
objtype=device secflags=FSF_DOM_ANY /dev/hd4
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/hd2
objtype=device secflags=FSF_DOM_ANY /dev/hd2
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/hd9var
objtype=device secflags=FSF_DOM_ANY /dev/hd9var
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/hd3
objtype=device secflags=FSF_DOM_ANY /dev/hd3
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/hd1
objtype=device secflags=FSF_DOM_ANY /dev/hd1
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/hd11admin
objtype=device secflags=FSF_DOM_ANY /dev/hd11admin
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/proc
objtype=device secflags=FSF_DOM_ANY /dev/proc
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/hd10opt
objtype=device secflags=FSF_DOM_ANY /dev/hd10opt
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/livedump
objtype=device secflags=FSF_DOM_ANY /dev/livedump
# setsecattr -o domains=privlvDom conflictsets=applvDom
objtype=device secflags=FSF_DOM_ANY /dev/backup_lv
objtype=device secflags=FSF_DOM_ANY /dev/backup_lv
# lssecattr -o /dev/hd4
/dev/hd4 domains=privlvDom conflictsets=applvDom objtype=device
secflags=FSF_DOM_ANY
secflags=FSF_DOM_ANY
#
In Example 8-33 on page 320 the following attributes were defined:
Domain The domains attribute is the domain to which the domain RBAC object will be associated
Conflict Set This is an optional attribute. By defining the conflictsets=applvDom, this object will not be accessible if the entity has an existing association to the applvDom domain.
Object Type This is the type of domain RBAC object. The objtype=device is used for a logical volume
Security Flags When the secflags attribute is set to FSF_DOM_ANY a subject may access the object when it contains any of the domains specified in the domains attribute
Device Name This is the full path name to the logical volume corresponding to the file system. As an example, /dev/hd2 is the logical volume corresponding to the /usr file system
The administrator will now use the setkst command to update the KST with the changes made with the setsecattr and mkdom commands.
Example 8-34 shows the setkst command being executed from the root user.
Example 8-34 Using the setkst command to update the KST
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# setkst
Successfully updated the Kernel Authorization Table.
Successfully updated the Kernel Role Table.
Successfully updated the Kernel Command Table.
Successfully updated the Kernel Device Table.
Successfully updated the Kernel Object Domain Table.
Successfully updated the Kernel Domains Table.
#
The administrator will now use the chuser command to associate the appuser account with the applvDom domain.
Example 8-35 shows the chuser command being executed by the root user.
Example 8-35 Using the chuser command to associate the appuser account with the applvDom domain
# lsuser -a domains appuser
appuser
# chuser domains=applvDom appuser
# lsuser -a domains appuser
appuser domains=applvDom
#
The administrator has now completed the domain RBAC configuration. The four application file systems have been defined as domain RBAC objects and the appuser has been associated with the applvDom domain.
The administrator has also defined the remaining file systems as domain RBAC objects. This restricts privileged access to users only associated with the privlvDom domain, and adds a conflict set to the applvDom domain.
The conflict set ensures that if the appuser account were to be granted an association to the privlvDom domain, the file system objects could not be modified with the privileged commands, because the privlvDom and applvDom domains are in conflict.
Example 8-36 The appuser account uses the swrole command to switch to the apps_fs_manage role
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ rolelist -a
apps_fs_manage aix.fs.manage.change
aix.fs.manage.create
aix.fs.manage.mount
aix.fs.manage.remove
aix.fs.manage.unmount
$ swrole apps_fs_manage
appuser's Password:
$
The appuser account may now use the privileged commands in the apps_fs_manage role.
In Example 8-37 the appuser uses the chfs command to increase the size of the /apps01 file system by 1 GB. This command will successfully complete because the /dev/appslv_01 device was defined as a domain RBAC object to which the appuser has been granted an association through the applvDom domain.
Example 8-37 shows the appuser account using the chfs command to add 1 GB to the /apps01 file system.
Example 8-37 The appuser account using the chfs command to add 1 GB to the /apps01 file system
$ df -g /apps01
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/appslv_01 1.25 0.18 86% 15 1% /apps01
$ chfs -a size=+1G /apps01
Filesystem size changed to 4718592
$ df -g /apps01
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/appslv_01 2.25 1.18 48% 15 1% /apps01
$
In Example 8-37 we see that the chfs command has been successful.
Next, the appuser uses the chfs command to increase the size of the /backup file system by 1 GB.
Example 8-38 shows the appuser account attempting to use the chfs command to add 1 GB to the /backup file system.
Example 8-38 The appuser account attempting to use the chfs command to add 1 GB to the /backup file system
$ df -g /backup
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/backup_lv 2.25 2.15 5% 5 1% /backup
$ chfs -a size=+1G /backup
/dev/backup_lv: Operation not permitted.
$ df -g /backup
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/backup_lv 2.25 2.15 5% 5 1% /backup
$
In Example 8-38, the chfs command was not successful.
The chfs command was not sucsessful because the /dev/backup_lv device was defined as a domain RBAC object but the appuser account has not been granted association to the privlvDom domain.
Domain RBAC has restricted the appuser account using the chfs command to change the /backup file system because the appuser account has no association with the privlvDom domain.
Even though the appuser account has used the swrole command to switch to the apps_fs_manage role, the privileged chfs command is unsuccessful because domain RBAC has denied the appuser account access based on the domain object attributes of the /backup_lv object and the domain association of the appuser account.
By using this methodology, domain RBAC has restricted the appuser to managing only the file systems for which it has direct responsibility, and excluded privileged access to the remaining file systems on the LPAR.
In Example 8-39 the appuser account changes directory to the /tmp file system and uses the touch appuser_tmp_file command to show that the appuser account may still access the /tmp file system, but may not execute privileged commands, even though the apps_fs_manage role is effective.
In Example 8-39, the appuser account may also run the whoami command which is located in the /usr/bin directory in the /usr file system.
The /usr file system was also defined as a domain RBAC object, but is still accessible from the appuser and other user accounts, though the appuser account may not perform privileged operations on the /usr file system as shown when the appuser account attempts to execute the chfs -a freeze=30 /usr command.
Example 8-39 The appuser account using the touch and whoami commands
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ rolelist -e
apps_fs_manage Manage apps filesystems
$ cd /tmp
$ touch appuser_tmp_file
$ ls -ltra appuser_tmp_file
-rw-r--r-- 1 appuser appgroup 0 Sep 13 19:44 appuser_tmp_file
$ whoami
appuser
$ chfs -a freeze=30 /usr
/dev/hd2: Operation not permitted.
$
The appuser and other user accounts may still access the domained file systems, such as the /tmp and /usr file systems as general users, but the privileged commands available to the appuser account in the apps_fs_manage role may not be used on file systems other than the /apps01, /apps02, /apps03 and /apps04 file systems.
File scenario - Restrict access
In a default installation of AIX, some files may be installed with DAC permissions that allow the files to be read by non-privileged users. Though the files may only be modified by the root user, these files may contain information that the administrator may not wish to be readable by all users.
By using domain RBAC, the administrator can restrict file access to only those user accounts that are deemed to require access.
In this scenario the administrator has been requested to limit read access of the /etc/hosts file to only the netuser user account. This can be accomplished by using domain RBAC.
In this scenario we have:
•An AIX V7.1 partition with enhanced RBAC enabled
•A non-privileged user named netuser
•A non-privileged user named appuser
In Example 8-40, the user netuser account uses the head -15 command to view the first 15 lines of the /etc/hosts file.
The ls -ltra command output shows that the DAC permissions allow any user account to view the /etc/hosts file.
Example 8-40 The netuser account - using the head -15 command to view the first 15 lines of the /etc/hosts file
$ id
uid=302(netuser) gid=204(netgroup) groups=1(staff)
$ ls -ltra /etc/hosts
-rw-rw-r-- 1 root system 2052 Aug 22 20:35 /etc/hosts
$ head -15 /etc/hosts
# IBM_PROLOG_BEGIN_TAG
# This is an automatically generated prolog.
#
# bos61D src/bos/usr/sbin/netstart/hosts 1.2
#
# Licensed Materials - Property of IBM
#
# COPYRIGHT International Business Machines Corp. 1985,1989
# All Rights Reserved
#
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
# @(#)47 1.2 src/bos/usr/sbin/netstart/hosts, cmdnet, bos61D, d2007_49A2 10/1/07 13:57:52
# IBM_PROLOG_END_TAG
$
In Example 8-41, the user appuser uses the head-15 command to view the first 15 lines of the /etc/hosts file. Again, the ls-ltra command output shows that the DAC permissions allow any user account to view the /etc/hosts file.
Example 8-41 The appuser account - using the head -15 command to view the first 15 lines of the /etc/hosts file
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ ls -ltra /etc/hosts
-rw-rw-r-- 1 root system 2052 Aug 22 20:35 /etc/hosts
$ head -15 /etc/hosts
# IBM_PROLOG_BEGIN_TAG
# This is an automatically generated prolog.
#
# bos61D src/bos/usr/sbin/netstart/hosts 1.2
#
# Licensed Materials - Property of IBM
#
# COPYRIGHT International Business Machines Corp. 1985,1989
# All Rights Reserved
#
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
# @(#)47 1.2 src/bos/usr/sbin/netstart/hosts, cmdnet, bos61D, d2007_49A2 10/1/07 13:57:52
# IBM_PROLOG_END_TAG
$
Both the netuser and appuser accounts are able to view the /etc/hosts file, due to the DAC of the /etc/hosts file.
By creating an RBAC domain and defining the /etc/hosts file as a domain RBAC object, access to the /etc/hosts file may be restricted, based upon the user account’s association with the RBAC domain.
In Example 8-42, the root user logs in and uses the mkdom command to create an RBAC domain named privDom. The privDom domain has a domain ID of 3, which has been automatically system generated because the administrator did not include a domain ID in the the mkdom command.
Example 8-42 Using the mkdom command to create the privDom domain
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# mkdom privDom
# lsdom privDom
privDom id=3
#
From the root user, the administrator next defines the /etc/hosts file as a domain RBAC object.
In Example 8-43, the administrator uses the setsecattr command to define the /etc/hosts file as a domain RBAC object and assign the RBAC domain as privDom. The objtype attribute is set as the type file.
Example 8-43 Using the setsecattr command to define the /etc/hosts file as a domain RBAC object
# setsecattr -o domains=privDom objtype=file secflags=FSF_DOM_ANY /etc/hosts
# lssecattr -o /etc/hosts
/etc/hosts domains=privDom objtype=file secflags=FSF_DOM_ANY
#
For these changes to be available for use, the root user must update the KST with the setkst command.
Example 8-44 on page 328 shows the lskst -t command being used to list the KST prior to the setkst command being run.
Once the setkst command is run, the privDom domain and /etc/hosts file are both updated into the KST and are available for use.
Example 8-44 Updating the KST with the setkst command
# lskst -t dom privDom
Domain "privDom" does not exist.
# lskst -t domobj /etc/hosts
Domain object "/etc/hosts" does not exist.
# setkst
Successfully updated the Kernel Authorization Table.
Successfully updated the Kernel Role Table.
Successfully updated the Kernel Command Table.
Successfully updated the Kernel Device Table.
Successfully updated the Kernel Object Domain Table.
Successfully updated the Kernel Domains Table.
# lskst -t dom privDom
privDom id=4
# lskst -t domobj /etc/hosts
/etc/hosts objtype=FILE domains=privDom
conflictsets= secflags=FSF_DOM_ANY
conflictsets= secflags=FSF_DOM_ANY
#
At this stage, the /etc/hosts file has been defined as domain RBAC object and the KST updated.
The /etc/hosts file will now operate as a domain RBAC object and restrict access to any user accounts that have not been associated with the privDom domain.
This can be tested by attempting to access the /etc/hosts file from the netuser and appuser accounts.
|
Note: The root user is automatically a member of all RBAC domains so does not require any special access to the privDom domain.
|
Example 8-45 and Example 8-46 on page 329 show the netuser account using the head -15 command to read the /etc/hosts file.
Example 8-45 The netuser account using the head -15 command to access the /etc/hosts file
$ id
uid=302(netuser) gid=204(netgroup) groups=1(staff)
$ ls -ltra /etc/hosts
-rw-rw-r-- 1 root system 2052 Aug 22 20:35 /etc/hosts
$ head -15 /etc/hosts
/etc/hosts: Operation not permitted.
$
Example 8-46 The appuser account using the head -15 command to access the /etc/hosts file
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ ls -ltra /etc/hosts
-rw-rw-r-- 1 root system 2052 Aug 22 20:35 /etc/hosts
$ head -15 /etc/hosts
/etc/hosts: Operation not permitted.
$
The netuser and appuser accounts are no longer able to access the /etc/hosts file, even though the /etc/hosts file DAC allows for read access by any user. This is because the /etc/hosts file is now a domain RBAC object and access is dependant on the privDom domain association.
In Example 8-47, the administrator associates the netuser account with the privDom domain by using the chuser command from the root user.
Example 8-47 Using the chuser command to grant the netuser account association to the privDom domain
# lsuser -a domains netuser
netuser
# chuser domains=privDom netuser
# lsuser -a domains netuser
netuser domains=privDom
#
Now that the netuser account has been associated with the privDom domain, the netuser account may again access the /etc/hosts file.
|
Note: Due to the chuser attribute change, the netuser account must log out and login for the domain=privDom association to take effect.
|
In Example 8-48 we see the netuser account using the head -15 command to access the /etc/hosts file.
Example 8-48 The netuser account using the head -15 command to access the /etc/hosts file
$ id
uid=302(netuser) gid=204(netgroup) groups=1(staff)
$ ls -ltra /etc/hosts
-rw-rw-r-- 1 root system 2052 Aug 22 20:35 /etc/hosts
$ head -15 /etc/hosts
# IBM_PROLOG_BEGIN_TAG
# This is an automatically generated prolog.
#
# bos61D src/bos/usr/sbin/netstart/hosts 1.2
#
# Licensed Materials - Property of IBM
#
# COPYRIGHT International Business Machines Corp. 1985,1989
# All Rights Reserved
#
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
#
# @(#)47 1.2 src/bos/usr/sbin/netstart/hosts, cmdnet, bos61D, d2007_49A2 10/1/07 13:57:52
# IBM_PROLOG_END_TAG
$
The netuser account is now able to access the /etc/hosts file.
Associating the netuser account with the privDom domain has allowed the netuser account to access the object and list the contents of the /etc/hosts file with the head -15 command.
Domain RBAC will still honor the DAC for the file object, so the netuser account will have only read access to the /etc/host file. Domain RBAC does not automatically grant write access to the file, but does allow the administrator to restrict the access to the /etc/hosts file without having to change the DAC file permission bits.
The appuser account will remain unable to access the /etc/hosts file because it has not been associated with the privDom domain.
Example 8-49 shows the appuser account attempting to access the /etc/hosts file by using the head -15 command.
Example 8-49 The appuser account using the head -15 command to access the /etc/hosts file
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ ls -ltra /etc/hosts
-rw-rw-r-- 1 root system 2052 Aug 22 20:35 /etc/hosts
$ head -15 /etc/hosts
/etc/hosts: Operation not permitted.
$
The appuser account is denied access to the /etc/hosts file because it does not have the association with the privDom domain.
The administrator has successfully completed the request because the /etc/hosts file is now restricted to access by only the netuser account.
More than one user can be associated with a domain, so were more users to require access to the /etc/hosts file, the administrator need only use the chuser command to grant those users association with the privDom domain.
The root user is automatically considered a member of all domains, so the root user remains able to access the /etc/hosts file.
|
Note: When restricting access to files, consider the impact to existing AIX commands and functions.
As an example, restricting access to the /etc/passwd file would result in non-privileged users being no longer able to successfully execute the passwd command to set their own passwords.
|
File scenario - Remove access
In this scenario we discuss how domain RBAC can be used to remove access to files or non-privileged users.
In a default installation of AIX, some files may be installed with DAC permissions that allow the files to be read by non-privileged users. Though the files may only be modified by the root user, these files may contain information that the administrator may not wish to be readable by all users.
By using domain RBAC, the administrator can remove file access to user accounts that are deemed to not require access to such files.
In this scenario the administrator has chosen to remove read access to the /etc/ssh/sshd_config file. This can be accomplished by using domain RBAC.
In this scenario we have:
•An AIX V7.1 partition with enhanced RBAC enabled
•A non-privileged user named appuser
In Example 8-50 on page 332 we see the user appuser using the head-15 command to view the first 15 lines of the /etc/ssh/sshd_config file.
We can see from the ls -ltra command output that the DAC permissions allow any user account to view the /etc/ssh/sshd_config file.
Example 8-50 The appuser account - using the head -15 command to view the first 15 lines of the /etc/ssh/sshd_config file
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ ls -ltra /etc/ssh/sshd_config
-rw-r--r-- 1 root system 3173 Aug 19 23:29 /etc/ssh/sshd_config
$ head -15 /etc/ssh/sshd_config
# $OpenBSD: sshd_config,v 1.81 2009/10/08 14:03:41 markus Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
$
As shown in Example 8-50, the /etc/ssh/sshd_config file has DAC permissions that allow all users on the LPAR to read the file.
By creating an RBAC domain and defining the /etc/ssh/sshd_config file as a domain RBAC object, the administrator may restrict access to the /etc/ssh/sshd_config to only user accounts with membership to the RBAC domain.
By not associating the RBAC domain to any user accounts, the RBAC object will not be accessible to any user accounts other than the root user.
In Example 8-51, the administrator uses the root user to create an RBAC domain named lockDom. The lockDom domain has a domain ID of 4, which has been automatically system generated because no domain ID was specified with the mkdom command.
Example 8-51 Using the mkdom command to create the lockDom domain
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# mkdom lockDom
# lsdom lockDom
lockDom id=4
#
The administrator next uses the setsecattr command to define the /etc/ssh/sshd_config file as a domain RBAC object.
In Example 8-52, the root user executes the setsecattr command to define the /etc/ssh/sshd_config file as a domain RBAC object and set the RBAC domain as lockDom.
Example 8-52 Using the setsecattr command to define the /etc/ssh/sshd_config file as a domain RBAC object
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# setsecattr -o domains=lockDom objtype=file
secflags=FSF_DOM_ANY /etc/ssh/sshd_config
secflags=FSF_DOM_ANY /etc/ssh/sshd_config
# lssecattr -o /etc/ssh/sshd_config
/etc/ssh/sshd_config domains=lockDom objtype=file secflags=FSF_DOM_ANY
#
The /etc/ssh/sshd_config file has now been defined as a domain RBAC object.
To update the RBAC database change into the KST, the administrator uses the setkst command.
Example 8-53 shows the root user running the lskst command to list the contents of the KST. The root user then updates the KST by running the setkst command.
Example 8-53 Using the setkst command to update the KST and the lskst command to list the KST
# lskst -t dom lockDom
Domain "lockDom" does not exist.
# lskst -t domobj /etc/ssh/sshd_config
Domain object "/etc/ssh/sshd_config" does not exist.
# setkst
Successfully updated the Kernel Authorization Table.
Successfully updated the Kernel Role Table.
Successfully updated the Kernel Command Table.
Successfully updated the Kernel Device Table.
Successfully updated the Kernel Object Domain Table.
Successfully updated the Kernel Domains Table.
# lskst -t dom lockDom
lockDom id=4
# lskst -t domobj /etc/ssh/sshd_config
/etc/ssh/sshd_config objtype=FILE domains=lockDom conflictsets= secflags=FSF_DOM_ANY
#
At this stage, the /etc/ssh/sshd_config file is now defined as a domain RBAC object and the KST updated. Access to the /etc/ssh/sshd_config file is now restricted to the root user and any user accounts that are associated with the lockDom domain.
Because no user accounts have an association with the lockDom domain, the /etc/ssh/sshd_config file is now only accessible by the root user.
Example 8-54 shows the appuser account attempting to access the /etc/ssh/sshd_config file with the head, more, cat, pg and vi commands:
Example 8-54 Using the head, more, cat, pg and vi commands to attempt access to the /etc/ssh/sshd_config file
$ id
uid=301(appuser) gid=202(appgroup) groups=1(staff)
$ head -15 /etc/ssh/sshd_config
/etc/ssh/sshd_config: Operation not permitted.
$ more /etc/ssh/sshd_config
/etc/ssh/sshd_config: Operation not permitted.
$ cat /etc/ssh/sshd_config
cat: 0652-050 Cannot open /etc/ssh/sshd_config.
$ pg /etc/ssh/sshd_config
/etc/ssh/sshd_config: Operation not permitted.
$ vi /etc/ssh/sshd_config
~
...
...
~
"/etc/ssh/sshd_config" Operation not permitted.
$
The appuser account is not able to access the /etc/ssh/sshd_config file.
The only user able to access the /etc/ssh/sshd_config file is the root user.
If the appuser account were to be associated with the lockDom domain, then the appuser account would again be able to access the /etc/ssh/sshd_config file, based on the file DAC permission.
The benefits of using domain RBAC to restrict file access include:
File modification There is no requirement to modify the file DAC settings, including ownership and bit permissions.
Quick to reinstate Reinstating the file access does not require the administrator to modify the file DAC. The administrator can generally reinstate the file access by removing the object from the domain RBAC and updating the KST.
Granular control The administrator may still grant access to the file object by associating user accounts with the RBAC domain, if required for temporary or long term access.
|
Note: When removing access to files consider the impact to existing AIX commands and functions.
As an example, removing access to the /etc/security/passwd file would result in non-privileged users no longer being able to execute the passwd command to set their own passwords.
|
Network scenario
In this scenario, domain RBAC will be used to restrict privileged access to an Ethernet network interface.
In domain RBAC, network objects may be either of two object types:
netint This object type is a network interface. As an example, the en0 Ethernet interface would be an object type of netint.
netport This object type is a network port. As an example, the TCP port 22 would be an object type of netport.
By using domain RBAC, the administrator can restrict a subject from performing privileged commands upon a netint or netport object.
In this scenario, the AIX V7.1 LPAR has two Ethernet network interfaces configured.
The administrator will use domain RBAC to:
•Allow the netuser account to use the ifconfig command on the en2 Ethernet interface.
•Restrict the appuser account from using the ifconfig command on the en0 Ethernet interface.
Unless noted otherwise, all commands in the scenario will be run as the root user.
The administrator first uses the lssecattr command to determine which access authorizations the ifconfig command requires.
Example 8-55 shows the root user using the lssecattr command to display the access authorizations required by the ifconfig command:
Example 8-55 Using the lssecatr command from the root user to list the access authorizations for the ifconfig command
# lssecattr -c -a accessauths /usr/sbin/ifconfig
/usr/sbin/ifconfig accessauths=aix.network.config.tcpip
#
The ifconfig command requires the aix.network.config.tcpip access authorization.
The administrator will now use the authrpt command to determine whether there is an existing role that contains the necessary access authorizations required for executing the ifconfig command. The authrpt -r command limits the output displayed to only the roles associated with an authorization.
Example 8-56 shows the authrpt -r command being used to report on the aix.network.config.tcpip authorization.
Example 8-56 Using the authrpt command from the root user to determine role association with the aix.network.config.tcpip authorization
# authrpt -r aix.network.config.tcpip
authorization:
aix.network.config.tcpip
roles:
#
The roles: field in Example 8-56 has no value returned, which shows that there is no existing role associated with the aix.network.config.tcpip authorization. The administrator must use the mkrole command to create a role and associate the aix.network.config.tcpip authorization to the role.
Example 8-57 on page 337 shows the administrator using the mkrole command to create the netifconf role and include the aix.network.config.tcpip authorization as the accessauths attribute. The administrator then updates the KST with the setkst command.
Example 8-57 Using the mkrole command from the root user to create the netifconf role and associate with the aix.network.config.tcpip authorization
# mkrole authorizations=aix.network.config.tcpip
dfltmsg="Manage net interface" netifconf
dfltmsg="Manage net interface" netifconf
# lsrole netifconf
netifconf authorizations=aix.network.config.tcpip rolelist=
groups= visibility=1 screens=* dfltmsg=Manage net interface
msgcat= auth_mode=INVOKER id=19
groups= visibility=1 screens=* dfltmsg=Manage net interface
msgcat= auth_mode=INVOKER id=19
# setkst
Successfully updated the Kernel Authorization Table.
Successfully updated the Kernel Role Table.
Successfully updated the Kernel Command Table.
Successfully updated the Kernel Device Table.
Successfully updated the Kernel Object Domain Table.
Successfully updated the Kernel Domains Table.
#
The administrator next uses the lsuser command to display the existing roles, if any, that the netuser command may have associated to it. The administrator then associates the netuser with the netifconf role, including any existing roles in the chuser command.
Example 8-58 shows the chuser command being used to associate the netuser account with the netifconf role. The lsuser command showed that the netuser did not have any existing roles.
Example 8-58 Using the chuser command from the root user to associate the netuser account with the netifconf role
# lsuser -a roles netuser
netuser roles=
# chuser roles=netifconf netuser
# lsuser -a roles netuser
netuser roles=netifconf
#
At this stage, the netuser account has been associated with the netifconf role and may execute the ifconfig privileged command.
The administrator may verify this by using the authrpt and rolerpt commands.
Example 8-59 shows the authrpt command being used to report the aix.network.config.tcpip authorization association with the netifconf role.
Example 8-59 also shows the rolerpt command being used to report that the netifconf role has an association with the netuser account.
Example 8-59 The root user using the authrpt and rolerpt commands
# authrpt -r aix.network.config.tcpip
authorization:
aix.network.config.tcpip
roles:
netifconf
# rolerpt -u netifconf
role:
netifconf
users:
netuser
#
The administrator now uses domain RBAC to restrict the authority of the netuser account’s usage of the ifconfig command so that the ifconfig command will only execute successfully when used upon the en2 Ethernet interface.
The administrator uses domain RBAC to:
1. Create two RBAC domains.
2. Create two domain RBAC objects.
3. Update the Kernel Security Tables (KST).
4. Associate the RBAC domain to the netuser account.
5. Attempt to use the ifconfig command to change the status of the en0 and en2 Ethernet interfaces.
In Example 8-60 the administrator uses the ifconfig -a command to display the network interfaces. The en0 and en2 Ethernet interfaces are both active, shown by the UP status.
Example 8-60 The ifconfig -a command to display the network inferface status
# ifconfig -a
en0: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet 192.168.101.12 netmask 0xffffff00 broadcast 192.168.101.255
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
en2: flags=5e080867,c0<UP,BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
inet 10.10.100.2 netmask 0xffffff00 broadcast 10.10.100.255
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
lo0: flags=e08084b,c0<UP,BROADCAST,LOOPBACK,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,LARGESEND,CHAIN>
inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
inet6 ::1%1/0
tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1
#
After verifying the names of the Ethernet network interfaces in Example 8-60, the administrator now begins the domain RBAC configuration.
Example 8-61 The mkdom command to create the netDom and the privNetDom RBAC domains
# mkdom netDom
# lsdom netDom
netDom id=5
# mkdom privNetDom
# lsdom privNetDom
privNetDom id=6
#
Next, in Example 8-62 the administrator uses the setsecattr command to define the en2 and en0 Ethernet network interfaces as domain RBAC objects. The setkst command is then run to update the KST.
Example 8-62 The setsecattr command being used by the root user to define the en0 and en2 domain RBAC objects
# setsecattr -o domains=netDom objtype=netint secflags=FSF_DOM_ANY en2
# setsecattr -o domains=privNetDom conflictsets=netDom
objtype=netint secflags=FSF_DOM_ANY en0
objtype=netint secflags=FSF_DOM_ANY en0
# lssecattr -o en2
en2 domains=netDom objtype=netint secflags=FSF_DOM_ANY
# lssecattr -o en0
en0 domains=privNetDom conflictsets=netDom objtype=netint secflags=FSF_DOM_ANY
# setkst
Successfully updated the Kernel Authorization Table.
Successfully updated the Kernel Role Table.
Successfully updated the Kernel Command Table.
Successfully updated the Kernel Device Table.
Successfully updated the Kernel Object Domain Table.
Successfully updated the Kernel Domains Table.
#
In Example 8-62 the administrator has included the conflictsets=netDom attribute when defining the en0 object. This means that if an entity were granted association with the privNetDom and the netDom, the entity would not be granted authorization to perform actions on the en0 object, because the privNetDom and netDom domains are in conflict.
|
Note: The root user has an automatic association to all domains and objects.
The root user does not honor the conflictsets attribute because the root user must remain able to access all domain RBAC objects.
|
The netuser next has its domain association extended to include the netDom domain. The netuser account is already associated with the privDom domain from a previous scenario. The privDom domain association is included in the chuser command, else access to the privDom domain would be removed.
Example 8-63 shows the chuser command being used to associate the netuser account with the netDom domain.
|
Note: The privDom domain will not be used in this scenario and should not be confused with the privNetDom domain, which is used in this scenario.
|
Example 8-63 Using the chuser command to associate the netuser account with the netDom domain
# lsuser -a domains netuser
netuser domains=privDom
# chuser domains=privDom,netDom netuser
# lsuser -a domains netuser
netuser domains=privDom,netDom
#
The administrator has now completed the domain RBAC configuration tasks.
The netuser account is now used to test the use of the ifconfig command and the domain RBAC configuration.
In Example 8-64 the netuser logs into the AIX V7.1 LPAR and uses the swrole command to switch to the netifconf role. The rolelist -e command shows that the netifconf role becomes the active role.
Example 8-64 The netuser account uses the swrole command to switch to the netifconf role
$ id
uid=302(netuser) gid=204(netgroup) groups=1(staff)
$ rolelist -a
netifconf aix.network.config.tcpip
$ swrole netifconf
netuser's Password:
$ rolelist -e
netifconf Manage net interface
$
In Example 8-65 on page 341 the netuser account uses the ifconfig command to display the status of the en2 Ethernet interface, showing that the status is UP. The ping command is used to confirm the UP status and has 0% packet loss.
The netuser account then uses the ifconfig en2 down command to inactivate the en2 interface. The ifconfig command no longer displays the UP status and the ping command returns 100% packet loss.
The netuser account has successfully used the ifconfig command to deactivate the en2 Ethernet interface.
Example 8-65 The netuser account using the ifconfig command to deactivate the en2 Ethernet interface
$ ifconfig en2
en2: flags=5e080867,c0<UP,BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
inet 10.10.100.2 netmask 0xffffff00 broadcast 10.10.100.255
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
$ ping -c2 -w 2 10.10.100.5
PING 10.10.100.5: (10.10.100.5): 56 data bytes
64 bytes from 10.10.100.5: icmp_seq=0 ttl=64 time=1 ms
64 bytes from 10.10.100.5: icmp_seq=1 ttl=64 time=0 ms
----10.10.100.5 PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0/0/1 ms
$ ifconfig en2 down
$ ifconfig en2
en2: flags=5e080866,c0<BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
inet 10.10.100.2 netmask 0xffffff00 broadcast 10.10.100.255
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
$ ping -c2 -w 2 10.10.100.5
PING 10.10.100.5: (10.10.100.5): 56 data bytes
0821-069 ping: sendto: The network is not currently available.
ping: wrote 10.10.100.5 64 chars, ret=-1
0821-069 ping: sendto: The network is not currently available.
ping: wrote 10.10.100.5 64 chars, ret=-1
----10.10.100.5 PING Statistics----
2 packets transmitted, 0 packets received, 100% packet loss
$
In Example 8-66, the netuser account then uses the ifconfig en2 up command to reactivate the en2 interface. The ifconfig command displays the UP status and the ping command returns 0% packet loss.
The netuser account has successfully used the ifconfig command to activate the en2 Ethernet interface.
Example 8-66 The netuser account using the ifconfig command to activate the en2 Ethernet interface
$ ifconfig en2 up
$ ifconfig en2
en2: flags=5e080867,c0<UP,BROADCAST,DEBUG,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
inet 10.10.100.2 netmask 0xffffff00 broadcast 10.10.100.255
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
$ ping -c2 -w 2 10.10.100.5
PING 10.10.100.5: (10.10.100.5): 56 data bytes
64 bytes from 10.10.100.5: icmp_seq=0 ttl=64 time=0 ms
64 bytes from 10.10.100.5: icmp_seq=1 ttl=64 time=0 ms
----10.10.100.5 PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
$
By using RBAC, the netuser account has been able to successfully use the ifconfig command to activate and deactivate the en2 Ethernet interface.
In Example 8-67 , domain RBAC is used to restrict the netuser account from using the ifconfig command to change the status en0 interface. When the netuser account uses the ifconfig en0 down command, the ifconfig command is not successful.
Example 8-67 The netuser account is unsuccessful in using the ifconfig command to inactivate the en0 Ethernet interface
$ id
uid=302(netuser) gid=204(netgroup) groups=1(staff)
$ rolelist -e
netifconf Manage net interface
$ ifconfig en0
en0: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet 192.168.101.12 netmask 0xffffff00 broadcast 192.168.101.255
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
$ ping -c2 -w 2 192.168.101.11
PING 192.168.101.11: (192.168.101.11): 56 data bytes
64 bytes from 192.168.101.11: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 192.168.101.11: icmp_seq=1 ttl=255 time=0 ms
----192.168.101.11 PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
$ ifconfig en0 down
0821-555 ioctl (SIOCIFATTACH).: The file access permissions do not allow the specified action.
$ ifconfig en0
en0: flags=1e080863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
inet 192.168.101.12 netmask 0xffffff00 broadcast 192.168.101.255
tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
$ ping -c2 -w 2 192.168.101.11
PING 192.168.101.11: (192.168.101.11): 56 data bytes
64 bytes from 192.168.101.11: icmp_seq=0 ttl=255 time=0 ms
64 bytes from 192.168.101.11: icmp_seq=1 ttl=255 time=0 ms
----192.168.101.11 PING Statistics----
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0/0/0 ms
$
Example 8-67 on page 343 shows the netuser account using the ifconfig command to display the status of the en0 Ethernet interface, showing that the status is UP. The ping command is used to confirm the UP status and has 0% packet loss.
The netuser account then uses the ifconfig en0 down command to inactivate the en0 interface.
Because the netuser account has no association with the privNetDom domain, the ifconfig command returns the message:
0821-555 ioctl (SIOCIFATTACH).: The file access permissions do not allow the specified action.
The ifconfig command is not successful and the status of the en0 Ethernet interface remains UP.
By using this methodology, domain RBAC has restricted the netuser account to using the ifconfig command to manage only the en2 network interface, and excluded privileged access to the en0 network interface.
In Example 8-62 on page 339 the administrator chose to use the setsecattr command with the optional conflictsets=netDom attribute. The conflictsets=netDom attribute can be used to further increase the security layer within the domain RBAC security framework.
Because the en0 object defines the domain attribute as privNetDom and the conflict set attribute is defined as netDom, the en0 object association will not be granted to an entity if the entity has associations to both the privNetDom and netDom domains.
In Example 8-68, the chuser command is used to add the privNetDom association with the netuser account. The existing associations with the privDom and netDom domains are included in the chuser command.
Example 8-68 The chuser command used to add the privNetDom association to the netuser account
# chuser domains=privDom,netDom,privNetDom netuser
# lsuser -a roles netuser
netuser roles=netifconf
#
Because the chuser command was used to grant the netuser account an association with the privDom,netDom and privNetDom domains and the en0 object includes the conflict set between the privNetDom and the netDom domain, the netuser account will not be granted access to the en0 object.
Example 8-69 shows the netuser account attempting to use the ifconfig command to deactivate the en2 and en0 Ethernet interfaces.
As in Example 8-65 on page 341, the ifconfig en2 down command is successful, because the netuser account has the netifconf role active and the domain RBAC configuration has been configured to allow for the operation of the ifconfig command on the en2 object.
In Example 8-69, the ifconfig en0 down command is not successful, because the conflictsets=netDom attribute does not allow the netuser account access to the en0 device.
Example 8-69 The netuser account using the ifconfig command to deactivate the en0 interface - the conflict set does not allow access to the en0 domain RBAC object
$ id
uid=302(netuser) gid=204(netgroup) groups=1(staff)
$ rolelist -a
netifconf aix.network.config.tcpip
$ swrole netifconf
netuser's Password:
$ ifconfig en2 down
$ ifconfig en0 down
0821-555 ioctl (SIOCIFATTACH).: The file access permissions do not allow the specified action.
$
8.2 Auditing enhancements
The following sections discuss the enhancements for auditing.
8.2.1 Auditing with full pathnames
The AIX audit subsystem allows auditing of objects with full path names for certain events, such as FILE_Open, FILE_Read and FILE_Write. This helps to achieve security compliance and gives complete information about the file that is being audited.
An option is provided to the audit command to enable auditing with full pathnames.
audit { on [ panic | fullpath ] | off | query | start | shutdown }{-@ wparname ...}
Likewise, the audit subroutine can also be used to enable full path auditing.
Example 8-70 shows how to enable or disable auditing with full pathnames.
Example 8-70 Configuring auditing with full pathnames
# audit query
auditing off
bin processing off
audit events:
none
audit objects:
none
# audit start
# audit off
auditing disabled
# audit on fullpath
auditing enabled
# cat newfile1
# auditpr -v < /audit/trail |grep newfile1
flags: 67109633 mode: 644 fd: 3 filename /tmp/newfile1
flags: 67108864 mode: 0 fd: 3 filename /tmp/newfile1
file descriptor = 3 filename = /tmp/newfile1
# audit query
auditing on[fullpath]
audit bin manager is process 7143522
audit events:
general - FS_Mkdir,FILE_Unlink,FILE_Rename,FS_Chdir,USER_SU,PASSWORD_Change,FILE_Link,FS_Chroot,PORT_Locked,PORT_Change,FS_Rmdir
........
........
8.2.2 Auditing support for Trusted Execution
Trusted Execution (TE) offers functionalities that are used to verify the integrity of the system and implement advanced security policies, which together can be used to enhance the trust level of the complete system. The functionalities offered can be grouped into the following:
•Managing the Trusted Signature Database
•Auditing integrity of the Trusted Signature Database
•Configuring Security Policies
New auditing events have been added to record security relevant information that can be analyzed to detect potential and actual violations of the system security policy.
Table 8-2 lists the audit events which have been added to audit Trusted Execution events.
Table 8-2 Audit event list
|
Event
|
Description
|
|
TEAdd_Stnz
|
This event is logged whenever a new stanza is being added to the /etc/security/tsd/tsd.dat (tsd.dat) database.
|
|
TEDel_Stnz
|
This event is logged whenever a stanza is deleted from the tsd.dat database.
|
|
TESwitch_algo
|
This event is logged when a hashing algorithm is changed for a command present in the tsd.dat database.
|
|
TEQuery_Stnz
|
This event is logged when the tsd.dat database is queried.
|
|
TE_Policies
|
This event is logged when modifying TE policies using the trustchk command. The various TE policies are listed below together with the possible values they can take:
•TE ON/OFF
•CHKEXEC ON/OFF
•CHKSHLIB ON/OFF
•CHKSCRIPT ON/OFF
•CHKKERNEXT ON/OFF
•STOP_UNTRUSTD ON/OFF/TROJAN
•STOP_ON_CHKFAIL ON/OFF
•LOCK_KERN_POLICIES ON/OFF
•TSD_FILES_LOCK ON/OFF
•TEP ON/OFF
•TLP ON/OFF
|
|
TE_VerifyAttr
|
This event is logged when the user attribute verification fails.
|
|
TE_Untrusted
|
Reports non-trusted files when they are executed
|
|
TE_FileWrite
|
Reports files that get opened in write mode
|
|
TSDTPolicy_Fail
|
Reports setting/setting of the Trusted Execution policy
|
|
TE_PermsChk
|
Reports when Owner/Group/Mode checks fail in the kernel
|
|
TE_HashComp
|
Reports when crypto hash comparison fails in the kernel
|
Recycling Audit trail files
Audit-related parameters are configured in the /etc/security/audit/config file. When the size of files /audit/bin1 or /audit/bin2 reaches the binsize parameter (defined in the config file) it is written to the /audit/trail file. The size of the trail file is in turn limited by the size of the / file system. When the file system free space reaches the freespace (defined in the config file) value, it will start logging the error message in the syslog. However, in case there is no space in the / file system, auditing will stop without affecting the functionality of the running system and errors will be logged in syslog.
To overcome this difficulty, tunable parameters have been provided in the /etc/security/audit/config file:
backupsize A backup of the trail file is taken when the size of the trail file reaches this value. The existing trail file will be truncated. Size should be specified in units of 512-byte blocks.
backuppath A valid full directory path, where a backup of the trail file needs to be taken.
In the /etc/security/audit/bincmds file, the auditcat command will be invoked in the following ways:
auditcat -p -s $backupsize -d $backuppath -o $trail $bin
or
auditcat -p -s <size value> -d <path value> -o $trail $bin
In the first case, it will replace the value of $backupsize and $backuppath from values mentioned in the /etc/security/audit/config file. In the later case it will take the actual values as specified at the command line.
The backup trail file name will be in the following format:
trail.YYYYMMDDThhmmss.<random number>
Example 8-71 shows the configuration of recycling of audit trail files.
Example 8-71 Recycling of audit trail files
# grep bincmds /etc/security/audit/config
cmds = /etc/security/audit/bincmds
# cat /etc/security/audit/bincmds
/usr/sbin/auditcat -p -s 16 -d /tmp/audit -o $trail $bin
# audit start
# pwd
/tmp/audit
# ls
trail.20100826T025603.73142
|
Note: If a copy of the trail file to newpath fails due to lack of space or any other reason, it will take the backup of the trail file in the /audit file system (or in the current file system if it is different from /audit, defined in the config file). However, if /audit is full, then it will not take the backup of the trail file and the legacy behavior will prevail, that is, auditing will stop and errors will be logged to syslog.
|
The auditmerge command is used to merge binary audit trails. This is especially useful if there are audit trails from several systems that need to be combined. The auditmerge command takes the names of the trails on the command line and sends the merged binary trail to standard output. Example 8-72 shows use of auditmerge and auditpr commands to read the audit records from the trail files.
Example 8-72 Merging audit trail files
auditmerge trail.system1 trail.system2 | auditpr -v -hhelrRtpc
8.2.3 Role-based auditing
Auditing has been enhanced to audit events on per role basis. This capability will provide the administrator with more flexibility to monitor the system based on roles.
In role-based auditing, auditing events are assigned to roles that are in turn assigned to users. This can be considered equivalent to assigning the audit events for all the users having those roles. Auditing events are triggered for all users who are having the role configured for auditing.
As an example, audit events EventA and EventB are assigned to role Role1. The users User1, User2 and User3 have been assigned the role Role1. When auditing is started, events EventA and EventB are audited for all three users: User1, User2 and User3. Figure 8-1 depicts role-based auditing.
Figure 8-1 Illustration of role-based auditing
Example 8-73 shows the usage of role-based auditing.
Example 8-73
# mkrole auditclasses=files roleA
# setkst
Successfully updated the Kernel Authorization Table.
Successfully updated the Kernel Role Table.
Successfully updated the Kernel Command Table.
Successfully updated the Kernel Device Table.
Successfully updated the Kernel Object Domain Table.
Successfully updated the Kernel Domains Table.
# mkuser roles=roleA default_roles=roleA userA
# passwd userA
Changing password for "userA"
userA's New password:
Enter the new password again:
# audit start
# login userA
userA's Password:
[compat]: 3004-610 You are required to change your password.
Please choose a new one.
userA's New password:
Enter the new password again:
*******************************************************************************
* *
* *
* Welcome to AIX Version 7.1! *
* *
* *
* Please see the README file in /usr/lpp/bos for information pertinent to *
* this release of the AIX Operating System. *
* *
* *
*******************************************************************************
$ rolelist -e
roleA
$ exit
.....
.....
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp)
# auditpr -v </audit/trail |grep userA
userA
FILE_Open userA OK Thu Aug 26 02:11:02 2010 tsm Global
FILE_Read userA OK Thu Aug 26 02:11:02 2010 tsm Global
FILE_Close userA OK Thu Aug 26 02:11:02 2010 tsm Global
....
....
8.2.4 Object auditing for NFS mounted files
All of the operations on the auditable objects residing on the NFS mounted file systems, are logged on the client, provided that there are no operations on those objects by the NFS server or by the other NFS clients, or fullpath auditing is enabled on the client. If fullpath auditing is not enabled and if the file is modified by the server or by other clients, the consecutive auditing might be undefined. This behavior is corrected by restarting audit on the client.
To illustrate, in the context of the Network File System (NFS), if an inode is reassigned to another file on the server side, the client will not be aware of it. Hence, it will keep track of the wrong files.
As a solution, if a file system is mounted on multiple clients, audit the operations on the server to get the exact log of the events or enable fullpath auditing on the client:
# audit on fullpath
By enabling fullpath auditing:
•If a file, say xyz, is deleted on the server and recreated with the same name (with the same or different inode), then the client will continue auditing it.
•If the file is deleted on the server and recreated with the same inode (but with a different name), then the client will not audit it.
8.3 Propolice or Stack Smashing Protection
Stack Smashing Protection is supported on AIX since AIX 6.1 TL4 and using XLC compiler Version 11. This feature can be used to minimize the risk of security vulnerabilities such as buffer overflows in AIX.
On AIX 7.1, most of the setuid programs are shipped with this feature enabled automatically and no explicit configuration is required.
For more information regarding the compiler option -qstackprotect, refer to the IBM XLC compiler version 11 documentation.
In Example 8-74, when the test program is compiled with the -qstackprotect option on the XLC v11 compiler and executed onthe AIX 6.1 TL6 or 7.1 system, buffer overflow will be detected, resulting in termination of the process.
Example 8-74 Propolice or Stack Smashing Protection
# cat test.c
char largebuffer[34];
main()
{
char buffer[31];
memcpy(buffer, largebuffer, 34);
}
# ./test
*** stack smashing detected ***: program terminated
IOT/Abort trap(coredump)
|
Note: Propolice may not detect all buffer overruns. Its main goal is to prevent buffer overruns from overwriting the stack in a way that could lead to execution of malicious code. So as long as other local variables are overwritten, Propolice may not trigger.
|
8.4 Security enhancements
The following sections describe additional security enhancements.
8.4.1 ODM directory permissions
The Object Data Manager (ODM) is a data manager used for storing system configuration information. On AIX, the directories and files that make up the ODM are owned by root and are part of the system group. Both owner and group have write permissions. The group write permission opens a security hole by allowing any user in the system group the ability to create and modify files. This puts the system at risk from corruption and the potential to give unauthorized access to system users.
This security vulnerability is resolved by removing the group write permissions on these two directories:
/etc/objrepos
/etc/lib/objrepos
8.4.2 Configurable NGROUPS_MAX
The current hardcoded value for the maximum number of groups a user can be part of is 128. On AIX 7.1, this limit has been increased to 2048 (NGROUPS_MAX). The new kernel parameter ngroups_allowed is introduced, which can be tuned in the range of 128 >= ngroups_allowed <= NGROUPS_MAX.
The default is 128. This tunable allows administrators to configure the maximum number of groups users can be members of. NGROUPS_MAX is the max value that the tunable can be set to.
The lsattr command shows the current ngroups_allowed value. The chdev command is used to modify the value. The smitty chgsys fastpath can also be used to modify this parameter. Programmatically, the sys_parm subroutine with the SYSP_V_NGROUPS_ALLOWED parameter can be used to retrieve the ngroups_allowed value.
Example 8-75 shows configuring the ngroups_allowed parameter.
Example 8-75 Modifying ngroups_allowed
# lsattr -El sys0 |grep ngroups_allowed
ngroups_allowed 128 Number of Groups Allowed True
# chdev -l sys0 -a ngroups_allowed=2048
sys0 changed
|
Note: The system must be rebooted in order for the changes to take effect.
|
8.4.3 Kerberos client kadmind_timeout option
When using authentication other than the KRB5 load module, such as Single Sign On (SSO), there can be long delays when the kadmind server is down. This is because there are multiple kadmind connect calls for each Kerberos task, which causes multiple tcp timeouts.
To solve this problem, a new option has been introduced in the /usr/lib/security/methods.cfg for the KRB5 load module, kadmind_timeout=<seconds>. The kadmind_timeout option specifies the amount of time for the KRB5 load module to wait before attempting a kadmind connect call after a previous timeout. If kadmind_timeout time has not elapsed since the last timeout, then the KRB5 load module will not attempt to contact the down server. Therefore, there will only be one timeout within the kadmind_timeout time frame. The KADMIND_TIMEOUT_FILE will be used to notify all processes that there was a previous timeout. Whenever a process successfully connects to the kadmind server, the KADMIND_TIMEOUT_FILE is deleted.
Example 8-76 shows a sample configuration from the /usr/lib/security/methods.cfg file.
Example 8-76 Kerberos client kadmind_timeout option
/usr/lib/security/methods.cfg:
KRB5:
program = /usr/lib/security/KRB5
program_64 = /usr/lib/security/KRB5_64
options = kadmind_timeout=300
KRB5files
options = db=BUILTIN,auth=KRB5
8.4.4 KRB5A load module removal
The KRB5 load module handles both KRB5 and KRB5A Kerberos environments. Hence the KRB5A load module has been removed from AIX 7.1.
8.4.5 Chpasswd support for LDAP
The chpasswd command administers users' passwords. The root user can supply or change users' passwords specified through standard input. The chpasswd command has been enhanced to set Lightweight Directory Access Protocol (LDAP) user passwords in an ldap_auth environment by specifying -R LDAP and not specifying the -e flag for encrypted format. If you specify the -e option for the encrypted format, the chpasswd command-crypted format and LDAP server-crypted format must match.
8.4.6 AIX password policy enhancements
The following are the major password policy enhancements.
Restricting user name or regular expression in the password
The AIX password policy has been strengthened such that passwords are not allowed to contain user names or regular expressions.
User name can be disallowed in the password by adding an entry with the key word $USER in the dictionary files. This key word cannot be part of any word or regular expression of the entries in dictionary files.
As an example, if root user has the entry $USER in the dictionary file, say dicfile, then the root cannot have the following passwords: root, root123, abcRoot, aRooTb, and so forth.
Example 8-77 shows how the password can be strengthened to not to contain any user names.
Example 8-77 Disallowing user names in passwords
# chsec -f /etc/security/user -s default -a dictionlist=/usr/share/dict/words
# tail /usr/share/dict/words
zoom
Zorn
Zoroaster
Zoroastrian
zounds
z's
zucchini
Zurich
zygote
$USER
$ id
uid=205(tester) gid=1(staff)
$ passwd
Changing password for "tester"
tester's Old password:
tester's New password: (the password entered is “tester”)
3004-335 Passwords must not match words in the dictionary.
tester's New password:
Enter the new password again:
Passwords can be further strengthened by disallowing regular expressions. This is achieved by including the regular expression in the dictionary file. To differentiate between a word and a regular expression in the dictionary file, a regular expression will be indicated with ‘*’ as first character.
For example, if administrator wishes to disallow any password beginning with “pas”, then he can make the following entry in the dictionary file:
*pas*
The first * will be used to indicate a regular expression entry and the remaining part will be the regular expression, that is, pas*. Example 8-78 on page 357 shows the complete procedure.
Example 8-78 Disallowing regular expressions in passwords
# tail /usr/share/dict/words
Zorn
Zoroaster
Zoroastrian
zounds
z's
zucchini
Zurich
zygote
$USER
*pas*
$ id
uid=205(tester) gid=1(staff)
$ passwd
Changing password for "tester"
tester's Old password:
tester's New password: (the password entered is “passw0rd”)
3004-335 Passwords must not match words in the dictionary.
tester's New password:
Enter the new password again:
Enforcing restrictions on the passwords
Passwords can be strengthened to force users to set passwords to contain the following character elements:
•Uppercase letters: A, B, C ... Z
•Lowercase letters: a, b, c .. z
•Numbers: 0, 1, 2, ... 9
•Special characters: ~!@#$%^&*()-_=+[]{}|;:'",.<>?/<space>
The following security attributes are used in this regard:
minloweralpha Defines the minimum number of lower case alphabetic characters that must be in a new password. The value is a decimal integer string. The default is a value of 0, indicating no minimum number. The allowed range is from 0 to PW_PASSLEN.
minupperalpha Defines the minimum number of upper case alphabetic characters that must be in a new password. The value is a decimal integer string. The default is a value of 0, indicating no minimum number. The allowed range is from 0 to PW_PASSLEN.
mindigit Defines the minimum number of digits that must be in a new password. The value is a decimal integer string. The default is a value of 0, indicating no minimum number. The allowed range is from 0 to PW_PASSLEN.
minspecialchar Defines the minimum number of special characters that must be in a new password. The value is a decimal integer string. The default is a value of 0, indicating no minimum number. The allowed range is from 0 to PW_PASSLEN.
The following rules are applied to these attributes, while setting the password:
•Rule 1
– If minloweralpha > minalpha then minloweralpha=minalpha
– If minupperalpha > minalpha then minupperalpha=minalpha
– If minlowercase + minuppercase > minalpha then minuppercase=minalpha – minlowercase
Table 8-3 gives an example scenario for Rule 1.
Table 8-3 Example scenario for Rule 1
|
Value set for the attributes in the /etc/security/user file
|
Effective value while setting the password per Rule 1
|
||||
|
minupperalpha
|
minloweralpha
|
minalpha
|
minupperalpha
|
minloweralpha
|
minalpha
|
|
2
|
3
|
7
|
2
|
3
|
2
|
|
8
|
5
|
7
|
2
|
5
|
0
|
|
5
|
6
|
7
|
1
|
6
|
0
|
•Rule 2
– If mindigit > minother then mindigit=minother
– If minspecialchar > minother then minspecialchar=minother
– If minspecialchar + mindigit >minother then minspecialchar = minother – mindigit
Table 8-4 gives an example scenario for Rule 2.
Table 8-4 Example scenario for Rule 2
|
Value set for the attributes in the /etc/security/user file
|
Effective value while setting the password per Rule 2
|
||||
|
minspecialchar
|
mindigit
|
minother
|
minspecialchar
|
mindigit
|
minother
|
|
2
|
3
|
7
|
2
|
3
|
2
|
|
8
|
5
|
7
|
2
|
5
|
0
|
|
5
|
6
|
7
|
1
|
6
|
0
|
|
Note: minother defines the minimum number of non-alphabetic characters in a password. The default is 0. The allowed range is from 0 to PW_PASSLEN.
|
Example 8-79 shows the usage of the minloweralpha security attribute.
Example 8-79 Usage of the minloweralpha security attribute
# chsec -f /etc/security/user -s default -a minloweralpha=5
# grep minloweralpha /etc/security/user
* minloweralpha Defines the minimum number of lower case alphabetic characters
* Note: If the value of minloweralpha or minupperalpha attribute is
* attribute. If 'minloweralpha + minupperalpha' is greater than
* 'minalpha - minloweralpha'.
minloweralpha = 5
# chsec -f /etc/security/user -s default -a minalpha=8
# grep minalpha /etc/security/user
* minalpha Defines the minimum number of alphabetic characters in a
* greater than minalpha, then that attribute is reduce to minalpha
* minalpha, then minupperalpha is reduce to
* 'minalpha - minloweralpha'.
* 'minalpha + minother', whichever is greater. 'minalpha + minother'
* should never be greater than PW_PASSLEN. If 'minalpha + minother'
* 'PW_PASSLEN - minalpha'.
minalpha = 8
Changing password for "tester"
tester's Old password:
tester's New password: (the password entered is “comp”)
3004-602 The required password characteristics are:
a maximum of 8 repeated characters.
a minimum of 8 alphabetic characters.
a minimum of 5 lower case alphabetic characters.
a minimum of 0 digits.
3004-603 Your password must have:
a minimum of 8 alphabetic characters.
a minimum of 5 lower case alphabetic characters.
tester's New password:
Enter the new password again:
$
8.5 Remote Statistic Interface (Rsi) client firewall support
In Rsi communication between xmservd/xmtopas and consumers, normally a random port was used by consumers. To force the consumers to open ports within the specified range, a new configuration line is introduced in AIX V7.1 and AIX 6.1 TL06. This new configuration enhancement is specified in the Rsi.hosts file. The Rsi agent first attempts to locate the Rsi.hosts file in the $HOME directory. If the file is not found, an attempt is made to locate the Rsi.hosts file in the /etc/perf directory, followed by a search in the /usr/lpp/perfmgr directory.
If an Rsi.hosts file is located, a specified range of ports is opened, including the starting and ending ports. If the Rsi.hosts file cannot be located in these directories or if the port range is specified incorrectly, the Rsi communication will make use of random ports.
You can specify the port range in the Rsi.hosts file as follows:
portrange <start_port> <end_port>
As an example:
portrange 3001 3003
Once the Rsi agent is started, it makes use of the ports in the specified range. In the above example, the Rsi agent will use 3001 or 3002 or 3003. In this example, the Rsi agent can only listen on three ports (3001, 3002 and 3003). Subsequent Rsi communication will fail.
8.6 AIX LDAP authentication enhancements
AIX LDAP authentication has been enhanced with the following new features.
8.6.1 Case-sensitive LDAP user names
The LDAP uid and cn attributes are used to store user account name and group account name. Both uid and the cn attributes are defined as directory string and were case insensitive. Starting with AIX 6.1 TL06 and AIX 7.1, both uid and cn can be case sensitive by enabling the caseExactAccountName configuration parameter in the /etc/security/ldap/ldap.cfg file. Table 8-5 provides a list of the caseExactAccountName values.
Table 8-5 The caseExactAccountName values
|
Name
|
Value
|
Comments
|
|
caseExactAccountName
|
no (Default)
|
Case insensitive behavior
|
|
yes
|
Exact case match
|
8.6.2 LDAP alias support
This feature allows AIX users to log in with an alias name defined in the LDAP directory entry, for example if an LDAP directory entry looks like the one shown in the following with an alias name usr1:
dn:uid=user1,ou=people,cn=aixdata
uid:user1
uid:usr1
objectclass:posixaccount
AIX LDAP authentication recognizes both uids user1 and usr1. If a command lsuser is run for user name user1 or usr1 it displays the same information because they are aliases. Previously, LDAP authentication only recognized uid user1.
8.6.3 LDAP caching enhancement
The AIX LDAP secldapclntd client daemon caches user and group entries retrieved from the LDAP server. AIX 6.1 TL06 and AIX 7.1 offers the ability to control the caching mechanism through a new attribute called TO_BE_CACHED. This change translates into having an additional column in the existing mapping files located in the /etc/security/ldap directory. All attributes in the LDAP mapping files have a value of yes in the TO_BE_CACHED new field by default. Administrators can selectively set an attribute to no to disable the caching of that attribute.
Table 8-6 provides a list of TO_BE_CACHED attribute values.
Table 8-6 TO_BE_CACHED valid attribute values
|
Name
|
Value
|
Comments
|
|
TO_BE_CACHED
|
no
|
LDAP client sends query directly to the LDAP server.
|
|
yes (Default)
|
LDAP client checks its cache before sending the query to the LDAP server.
|
8.6.4 Other LDAP enhancements
The following are additional LDAP enhancements:
•AIX LDAP supports Windows 2008 Active Directory (AD) and Active Directory application mode (ADAM).
•The lsldap command lists users, groups, NIS entities (hosts, networks, protocols, services, rpc, AND netgroup), automount maps, and RBAC entries (authorizations, roles, privileged commands, and devices). This command is extended to cover advance accounting.
•The AIX LDAP module is a full functional module covering both authentication and identification. It cannot be used as an authentication-only module as some customers have requested. This functionality is enhanced to have the same module support as a full functional module or an authentication-only module.
8.7 RealSecure Server Sensor
Multi-layered prevention technology in IBM RealSecure Server Sensor for AIX guards against threats from internal and external attacks.
Refer to the following website for further details about this product:
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.