AIX 3.2 Security Tips and Techniques

This section describes the tips and techniques of security tools available on AIX systems.

Security Tools Overview

The set of security tools is very big, because every tool of an operating system needs some level of security. You can find several security books on the behaviour of the classical file operations such as cp or mv commands. This section only discusses about security goodies you can use to improve your security properties and policies.

The examples given here focus only on the current topic, and dotted lines mean there is other information that isn't relevant. For example, in a stanza, if some existing attributes aren't useful for the current topic, they are replaced by dotted lines which are shifted with one tabulation character. See Figure - Banner for Login Prompt.

This part shows security implementation by means of the security files, sometimes with security commands. However, you can use either the SMIT interface, administration commands or administrative functions in a C program in order to do the same action as described.


**** NOTE: **** In the future, IBM may modify the format of some of these files, and it happens that some attributes change from one file to another file, as shown in Login Information. However, it is easier to explain security with the security files. It means that if you implement new security functions, you must use commands or system calls.

The directory /etc/security is a repository for many security files. This directory is accessible either with the superuser privileges or if a user belongs to the security group.


**** NOTE: **** Most of these files use the "*" character as the comment character and not the standard "#" character.

This section is split in thematic parts and often deals with different security files. That's why a security file may be discussed in different parts of this section.

Machine Access

This part discusses the access in the operating system and the first screen of a terminal.

Physical Access Control

A basic form of access control is the physical access control. The computer data is physically protected by, for example, a lockable case. This case is constructed in such a way that breaking into it causes irreparable damage. This damage allows the security violation to be detected. Since the identity of the responsible individual is probably unknown, physical control usually does not provide full accountability.

Physically the RISC System/6000 is well protected against unauthorized access. All models have a three positions key switch on the front of the machines. A diagram of the front panel key switch and the function of each position follows.


Figure: Functions on the Key Switch Positions

Normal
The usual working position. The machine can boot from any trusted device, which does not include the diskette device. The boot device will depend upon the setting of the bootlist for normal mode.
Secure
This is the recommended position for a secure system. After the system has booted, the key can be turned into this position and the key removed from the lock. The system will work normally in this position. However rebooting the system in secure mode is not possible. A cold or warm boot is disallowed in secure mode. Also the reset button is disabled. For a reboot the key position must be either in normal or service mode only.
Service
The system can boot from a boot device as defined in the service mode bootlist. This is an insecure position, since booting from diagnostics or from a bootable media will give the user unlimited root access.

Only in this position, you can open the desktop model box. The key can be used in another lock (at the back of the machine), in order to lock the box and prevent access to the plug panel.

Login Process

The first screen displayed on a terminal is the banner login. For security reasons, this screen must not contain any information of the previous user. This is a C2 requirement called reuse object.

Login Information

The /etc/security/login.cfg file allows you to define a banner in the herald stanza. This banner is defined as a character string and observes the classical rules of C language. For example, a newline is the character "\n". To clean the previous session with the banner, you have to insert 25 new lines before the login prompt.


# cat /etc/security/login.cfg
. . . . . . . . . .
/dev/pts0:
herald = "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\rIT SC Aust
in Texas\n\rgandalf machine\n\r/dev/pts0 login: "
. . . . . . . . . .
. . . . . . . . . .
# exit
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
ITSC Austin Texas
gandalf machine
/dev/pts0 login: "

Figure: Banner for Login Prompt

The information you get during the login is also very important. You can get, for example:

  1. The name of the machine you are logging into
  2. The type and release of the operating system: AIX Version 3.2.5, Solaris** Version 2.1, HP-UX**, and so on
  3. Warning about the future maintenance halt
  4. General information
  5. Specific group information

The login information can be split in several parts:

You have to choose the best way to display this information. For example, don't display the type of operating system and the future maintenance halt warning in the login prompt because this is interesting information for a hacker! See Figure - Banner for Login Prompt as an example of login prompt.

After a successfull login, the AIX system displays also very important information such as the last successfull login and the last unsuccessfull login. See Figure - Content of the lastog File for more details on the /etc/security/lastlog file. Before AIX 3.2.4, this information was stored in the /etc/security/user file.


# cat /etc/security/lastlog
. . . . . . . . . .
riche:
time_last_login = 753039794
tty_last_login = pts/2
host_last_login = bruce
unsuccessful_login_count = 2
time_last_unsuccessful_login = 753033466
tty_last_unsuccessful_login = pts/3
host_last_unsuccessful_login = bruce
. . . . . . . . . .
#

Figure: Content of the lastog File

A private file called .hushlogin in the user direcory allows you to suppress these messages and also the message of the day. This functionality is very useful for an improved working of uucico, the uucp carrier. However, since the users have to look at these messages, the administrator must suppress these files if they exist. He also has to advertise users how important is to read these messages.

In the /etc/profile file, you can test the user identifier, therefore administrators can send a specific information to this user.


**** NOTE: **** Administrators have to take care by limiting the quantity of information that users receive at each login.

Authorized Port List

You can define a list of authorized ports for each user. In Figure - How to Define the Authorized Ports List, there is no limitations for riche; daniel can't successfully connect on /dev/tty0 port and invite can only use remote access. This also works for the su command.


# cat /etc/security/user
. . . . . . . . . .
riche:
ttys = ALL
. . . . . . . . . .
. . . . . . . . . .
daniel:
ttys = ALL,!/dev/tty0
. . . . . . . . . .
. . . . . . . . . .
invite:
ttys = /dev/pts,!/dev/hft,!/dev/tty0
. . . . . . . . . .
. . . . . . . . . .
#

Figure: How to Define the Authorized Ports List

Trusted Path

To obtain the user name with its password, some hackers display a false banner login prompt. To avoid this, you must use a mechanism called trusted path. If you launch a trusted path, you are sure to make a real connection. There is no way to realize this on a classical UNIX operating system. However, AIX implements this mechanism by means of the Secure Attention Key (SAK). This is a sequence of key strikes (control x, control r), which you can't modify. This sequence is coded inside the tty driver and also in the telnetd daemon. By default, this mechanism isn't set on. To put it on, you have to configure the port and the user. Only when both are configured you can use the SAK. To set it up, see Figure - How to Enable SAK.


# cat /etc/security/login.cfg
. . . . . . . . . .
/dev/console:
sak_enabled = true
. . . . . . . . . .
. . . . . . . . . .
# cat /etc/security/user
. . . . . . . . . .
riche:
tpath = on
. . . . . . . . . .
. . . . . . . . . .
#

Figure: How to Enable SAK

If you SAK during login, you access a trusted login. If you SAK during session, you change shell to a trusted shell. This new shell only accesses special commands, which have the TCB bit set. For example the tvi command is a restricted editor with no escape shell. The passwd command is another example, discussed in Password Change.

General User Configuration

This part discusses the configuration related to users and security.

User Security

To follow the C2 guidelines, the password must not be in the /etc/passwd file anymore, but in another file, /etc/security/passwd, which is inaccessible for non administrator users.

Hiding Password File

The /etc/passwd file contains the character "!" in place of the password. See Figure - User Entries Example in the Password Files. The other parameters are unchanged as in the standard UNIX /etc/passwd file. The /etc/security/passwd file contains for each user:


# cat /etc/passwd
. . . . . . . . . .
riche:!:21:9:Francois Riche:/home/riche::/usr/bin/ksh
. . . . . . . . . .
# cat /etc/security/passwd
. . . . . . . . . .
riche:
password = s2HJ.GS5bnNs.
lastupdate = 752371547
flags =
. . . . . . . . . .
#

Figure: User Entries Example in the Password Files

If you put back the password from /etc/security/passwd to /etc/passwd instead of the "!", you can use this /etc/passwd file on other classical UNIX operating systems. The cypher password algorithm is the same (see the crypt function). For example, Solaris has used a similar mechanism to implement C2. However, the name is /etc/security/passwd.adjunct, and the stanza format is different.

Gecos Field

The chfn command allows every user to change the field called Gecos as shown in Figure - Gecos Field Change.


$ chfn riche
riche's current gecos:
"francois riche"
Change (yes) or (no)? > yes
To?>Francois Riche
$

Figure: Gecos Field Change

This field is very important for the mail and must contain the real user name as shown in Figure - User Entries Example in the Password Files. Now, you can send local mail to riche or to Francois.Riche.

New Authentication Features

The /etc/security/user file contains many security user features:




# cat /etc/security/user
. . . . . . . . . .
mail:
login=false
rlogin=false
auth1=SYSTEM;riche,SYSTEM;daniel
. . . . . . . . . .
. . . . . . . . . .
riche:
auth1=SYSTEM,NOTWICE;riche
. . . . . . . . . .
. . . . . . . . . .
# cat /etc/security/login.cfg
. . . . . . . . . .
NOTWICE:
program=/etc/security/notwice
. . . . . . . . . .
# cat /etc/security/notwice
WHO=`who | grep $1 |wc -l`
if [ $WHO -ge 1 ]
then
echo "You are already connected"
exit 1
else
exit 0
fi
#

Figure: Multiple and New Authentication Methods

The mail account is only accessible by the su command. The su command will ask for the riche user password and then the daniel user password. The word riche and daniel are passed to the authenticate method as arguments. These words must represent an account with a password. Such an account may exist just for the password.

The riche user account needs a classical password and then checks if you are not already connected.

To see all user attributes, you may use the lsuser -f riche command, which displays them in the stanza format.

Users Configuration

Shell

The /etc/security/login.cfg file allows you to define the list of shells you can use as login shell for users, as shown in Figure - Login Shells List.


# cat /etc/security/login.cfg
. . . . . . . . . .
usw:
shells = /bin/sh,/bin/bsh,/bin/ksh,/bin/tsh,. . . .
maxlogins = 32
. . . . . . . . . .
#

Figure: Login Shells List

The csh shell is removed in the example above because it doesn't use any general profile file like the /etc/profile file.
Without asking an administrator, a user can choose his prefered shell from this list with the chsh command. If you use uucp services, don't forget to put the /usr/lib/uucp/uucico binary in this list.

The maxlogins attribute is your user number license. This number must be the same as the one in your contract.

Bourne sh and korn ksh allow you to define a timeout on idle shell. There is a very secure way to enforce the timeout. However, the way is different for these two shells as shown in Figure - Korn Shell Timeout Behaviour.

User Environment

Administrators can set environment variables in three files:

The /etc/security/environ file is very useful to set user specific environment variables. The /etc/environment file is very useful to set general environment variables. The Figure - Environment Files Configuration shows you how to set up these files. They are not script shells.


# cat /etc/security/environ
. . . . . . . . . .
riche:
usrenv="MAIL=/usr/spool/mail/riche,TMOUT=300"
. . . . . . . . . .
. . . . . . . . . .
# cat /etc/environment
. . . . . . . . . .
ODMDIR=/etc/objrepos
TZ=. . . .
. . . . . . . . . .
TMOUT=900
TIMEOUT=15
. . . . . . . . . .
#

Figure: Environment Files Configuration

In case of conflict as shown for TMOUT variable, the /etc/security/environ setting is the one taken. That means the TMOUT value is 300 in the example above. You can also set environment variables with the /etc/profile file. This is very useful for a computed variable, such as TERM=`termdef`, where the variable TERM is set with the output of the termdef command. Since the /etc/profile file is a script shell, you can use it to run some shell commands. Take care, if you set an environment variable in the /etc/profile file, you overwrite the setting of both /etc/security/environ and /etc/environment files.

A user environment variable should be constant for some security reasons, for example the timeout on idle shell. You can use the read only characteristic of variables. This locks the value of a variable during all the session. This is done by the readonly command. For example: readonly TMOUT. With the AIX ksh shell, the read only characteristic is inherited across the fork operation as shown in Figure - readonly Feature Behaviour.


$ toto=titi
$ export toto
$ readonly toto
$ readonly
LOGNAME=riche
toto=titi
$ ksh
$ readonly
LOGNAME=riche
toto=titi
$ sh
$ readonly
$

Figure: readonly Feature Behaviour

Take care, because the TIMEOUT variable unit is in minutes,
while the TMOUT variable unit is in seconds plus a grace period of one minute preceded by a warning as shown in Figure - Korn Shell Timeout Behaviour.


$ TMOUT=2
$
shell time out in 60 seconds

$
shell time out in 60 seconds
ksh[2]: timed out waiting for input

Figure: Korn Shell Timeout Behaviour

User Limitation

Administrators have to set the different resource limits. In a security context, if the user is not a developer, you must set the core limit to zero to avoid core dumped. It may happen that some important information stays inside a core.

Usually, administrators use tools such as quotas. This limits consumers excessive use of disk resource, see User Resource Management.

Timer Daemon Usage

The crontab, at, batch commands may be denied or authorized to users. In the /var/adm/cron directory, you can create these files:

Group Configuration

In UNIX systems, the group strategy is a way to permit or deny rights to an object for a group of users. The AIX group behaviour is the same as the BSD one:

The setuid bit set on a directory, means that when a user creates a file, the owner group is the same as the parent directory, not the principal group of this user.

AIX allows what we call an administrator delegation. For instance, a user may add or remove another user from a group. This functionality needs many prerequisites such as:

Figure - How to Delegate Group Management shows how to configure this.


# cat /etc/security/user
. . . . . . . . . .
riche:
admin = true
. . . . . . . . . .
. . . . . . . . . .
# cat /etc/group
. . . . . . . . . .
security:!:7:root,riche
. . . . . . . . . .
# cat /etc/security/group
. . . . . . . . . .
itsc:
adms = root,riche
admin = false
. . . . . . . . . .
#

Figure: How to Delegate Group Management

When this is done, you can use the chgroup command to add or delete a user, see the example in Figure - How to Add a Group Member without Superuser Authority.


$ id
uid=203(riche) gid=1(staff) groups=7(security)
$ lsgroup -f itsc
itsc:
id=200
admin=false
users=irwin
adms=root,riche

$ chgroup users=irwin,daniel itsc
$ lsgroup -f itsc
itsc:
id=200
admin=false
users=irwin,daniel
adms=root,riche

$

Figure: How to Add a Group Member without Superuser Authority

In this case, you have to give the complete list of users each time you add a user. You can get this list with the lsgroup -f itsc command.


$ id
uid=203(riche) gid=1(staff) groups=7(security),201(jeu)
$ lsgroup -f jeu
jeu:
id=201
admin=false
users=riche
adms=riche
$ ls -l prog database
-rw-r----- 1 riche staff 45 Nov 16 15:49 database
-rwxr-xr-x 1 riche staff 13 Nov 16 15:40 prog
$ chgrp jeu database prog
$ ls -l prog database
-rw-r----- 1 riche jeu 45 Nov 16 15:49 database
-rwxr-xr-x 1 riche jeu 13 Nov 16 15:40 prog
$ su daniel
daniel's Password:
$ id
uid=205(daniel) gid=1(staff)
$ prog
cat: cannot open database
$ exit
$ id
uid=203(riche) gid=1(staff) groups=7(security),201(jeu)
$ chgroup users=riche,daniel jeu
$ lsgroup -f jeu
jeu:
id=201
admin=false
users=riche,daniel
adms=riche
$ su daniel
daniel's Password:
$ id
uid=205(daniel) gid=1(staff) groups=201(jeu)
$ prog
This is only accessible by the prog program.
$

Figure: File Access Management Using Group Delegation

If you are administrator, you are considered as one of the owner of this group and you can use the chgrp command of this group on a file.

The setgroups command allows you to add or delete groups you belong to. An example follows using the setgroups command.


$ setgroups
riche:
user groups = staff,security,jeu
process groups = staff,security,jeu

$ cd /etc/security
$ setgroups -d security
$ ls
.: No permission
$ setgroups
riche:
user groups = staff,security,jeu
process groups = staff,jeu

$ id
uid=203(riche) gid=1(staff) groups=201(jeu)
$
$ setgroups -a security
$ ls
audit limits oenviron osysck.cfg user
environ login.cfg ogroup ouser
. . . . . . . . .
$ id
uid=203(riche) gid=1(staff) groups=7(security),201(jeu)
$

Figure: setgroups Example

Secure Password

Password Configuration

Proper password management can only be accomplished through user education. However, to provide some additional security, the AIX V3 system provides configurable password restrictions. These allow the administrator to impose some rules for the passwords users will define, and to force passwords to be changed regularly. These restrictions are recorded in the pw_restrictions stanza of the /etc/security/login.cfg file, and are enforced whenever a new password is defined for a user or group. Note that all the restrictions are per system, not per user; if proper password security is to be maintained, all passwords should be similarly protected.

Apply the restrictions sensibly. Attempts to be too restrictive, such as limiting the password space (making guessing easier) or forcing the user to select difficult to remember passwords (which are then written down) can jeopardize the password security. At last, password security depends on the user's behaviour. Simple password restrictions, coupled with proper guidelines and an occasional audit (asking the user what their current password is to see if it is non-trivial) is the best policy.

The restrictions that can be applied are:

minage
The minimum number of weeks that must pass before a password can be changed. This prevents a user to quickly change twice its password, thus he can't set the first one at the second time the password is changed.
maxage
The maximum number of weeks that can pass before a password must be changed. An intelligent way to build a password is better than a too frequent password change policy. The most important is the quality of the password. If this attribute has a value of 0, no password login is allowed. The minimum value is 1.
minalpha
The minimum number of alphabetic characters the new password must contain.
minother
The minimum number of non-alphabetic characters the new password must contain (other characters are any ASCII printable characters which are nonalphabetic and are not National Language code points).
**** NOTE: **** The minimum length of a password on the system is minalpha + minother. The maximum length of a password is eight characters.
maxrepeats
The maximum number of times a character can appear in the new password.
mindiff
The minimum number of characters in the new password that must be different from the characters in the old password.
The following Figure - Password Restrictions Example is a password restrictions example.


# cat /etc/security/login.cfg
. . . . . . . . . .
pw_restrictions:
maxage = 24
minage = 1
minalpha = 5
minother = 2
mindiff = 3
maxrepeats = 2
. . . . . . . . . .
#

Figure: Password Restrictions Example

The following table gives recommended, default, and maximum values for each of these restrictions. The default values are applied if the pw_restrictions stanza is missing from the /etc/security/login.cfg file, or if a particular attribute is not defined. Secure environments should use the recommended values, and even systems used only as personal workstations should require a password of some sort, especially if they are connected to any network.


Table: Values for Password Restrictions

Restrictions should be set so that passwords are hard to guess, not hard to remember. Passwords that are hard to remember are often written down somewhere. This compromises system security.

Password Change

Another threat is when you change your password. To avoid trojan horse (a false passwd command), you have to use the trusted path again. See Trusted Path. The second possibility of trusted paths is to access a trusted shell called tsh by invoking SAK. Take care when you strike SAK, because all the processes attached to this port are killed by the system. See in Figure - Secure Way to Change the Password an example to change the password with a secure way.


$ ^X^R                                <--- SAK
tsh> tty
tsh: /bin/tty: not a trusted process
tsh> passwd
Changing passwd for "riche"
. . . . . . . . . .
tsh> shell
$

Figure: Secure Way to Change the Password

A new command allows to query information about users and modify the flag in the /etc/security/passwd file as shown
in Figure - Password Management with pwdadm Command: the pwdadm command.


# pwdadm -q riche
riche:
lastupdate = 752371547

# pwdadm -f ADMCHG riche
# pwdadm -q riche
riche:
lastupdate = 752371547
flags = ADMCHG

# pwdadm -c riche
# pwdadm -q riche
riche:
lastupdate = 752371547

#

Figure: Password Management with pwdadm Command

Access Control

This section discusses the access control of objects. Objects managed in AIX security are called files in the UNIX understanding, such as every leaf of the file systems tree: real files, directories, devices, sockets and named pipes. For example, tty uses a set of permissions (rwx user group others) to prevent someone else from sending you messages on your screen. Besides, the IPC mechanism, which is not integrated in file systems, also uses access control.

UNIX Permissions

The UNIX permissions are defined by a set of permissions: read, write, execute rights; and a set of subjects: owner user, owner group and the others. When a subject wants to work with an object, its effective uid matches these permissions:

Figure - UNIX Permissions Examples shows two examples.


$ ls -l fil
-r--rw-rwx 1 riche staff 11 Nov 15 18:41 fil
$ id
uid=203(riche) gid=1(staff)
$ cat fil
#!/bin/ksh
$ echo "echo coucou" > fil
ksh: fil: cannot create
$ su daniel
daniel's Password:
$ id
uid=205(daniel) gid=1(staff)
$ echo "echo coucou" > fil
$ fil
ksh: fil: permission denied
$

Figure: UNIX Permissions Examples

Figure - Directly Test Your Rights shows you a little script shell for your tests.


$ cat access
#!/bin/ksh
echo -n "$1: "
if test -r $1
then
echo -n 'r'
else
echo -n '-'
fi
if test -w $1
then
echo -n 'w'
else
echo -n '-'
fi
if test -x $1
then
echo 'x'
else
echo '-'
fi
$ id
uid=203(riche) gid=1(staff)
$ access fil
fil: r--

Figure: Directly Test Your Rights

AIX Access Control List

AIX introduces a very important extension to UNIX permissions, which is called Access Control List (ACL). This mechanism is used to directly specify permissions for many other users or many other groups as shown in Figure - Extensions Permissions Examples.

Access control lists are maintained by the commands: aclget, acledit, and aclput. The EDITOR variable should be set to the whole path name of the editor you wish to use with acledit command. If you use the vi editor, you can modify the file to look as shown in Figure - Simple ACL Examples.


$ ls -l fil
-r--rw-rwx 1 riche staff 23 Nov 16 11:59 fil
$ export EDITOR=/usr/bin/vi
$ acledit fil
attributes:
base permissions
owner(riche): r--
group(staff): rw-
others: rwx --> others: ---
extended permissions
disabled
:x
Should the modified ACL be applied? (yes) or (no) yes
$ ls -l fil
-r--rw---- 1 riche staff 23 Nov 16 11:59 fil
$

Figure: Simple ACL Examples

If any errors like unknown user ID or unknown group ID are displayed, the vi editor automatically invokes ACL again. You can use the ls -e command to find out if there are some extended permissions as shown in Figure - Extensions Permissions Examples.


$ id
uid=205(daniel) gid=1(staff)
$ ls -l fil
-r--rw---- 1 riche staff 23 Nov 15 18:46 fil
$ ls -e fil
-r--rw----+ 1 riche staff 23 Nov 15 18:46 fil
$ aclget fil
attributes:
base permissions
owner(riche): r--
group(staff): rw-
others: ---
extended permissions
enabled
specify r-- u:daniel
permit r-x g:system
$ access fil
fil: r--
$

Figure: Extensions Permissions Examples

This mechanism is an extension to POSIX 1003.6 standard about security. DCE also implements the POSIX rules, but not in the same way. Our advice is to limit the AIX possibilites to follow the general POSIX rules and to not diverge with DCE behaviour. The POSIX mechanism is the same as the UNIX one, in three times: user, group and others:

You can follow this decision algorithm if you use only the specify right quality for users and the permit right quality for groups as shown in Figure - Extensions Permissions Examples. You can also use the AIX ACL goodies for deny access to users or make a composed permissions access as shown in Figure - Complex ACL Examples.


$ id
uid=205(daniel) gid=1(staff)
$ aclget fil
attributes:
base permissions
owner(riche): rw-
group(staff): rw-
others: rwx
extended permissions
enabled
deny rwx u:guest
permit --x u:daniel
specify rw- u:daniel,g:staff,g:itsc
$ access fil
fil: rwx
$ su
root's Password:
# chgroup users=daniel itsc
# lsgroup -f itsc
itsc:
id=200
admin=false
users=daniel
adms=root
# exit
$ id
uid=205(daniel) gid=1(staff) groups=200(itsc)
$ access fil
fil: rw-
$

Figure: Complex ACL Examples


**** NOTE: **** The use of chmod command with absolute attributes disables your extended ACL.

Two attributes also exist in the access control list: setuid (SUID) and setgid (SGID), as shown in Figure - Special Attributes.


$ ls -l fil
-rwsr-rxr-x 1 riche staff 23 Nov 16 14:13 fil
$ aclget fil
attributes: SUID
base permissions
owner(riche): rwx
group(staff): r-x
others: r-x
extended permissions
disabled
$

Figure: Special Attributes

The attributes setuid and setgid are explained in
Privilege.

Privilege

In UNIX, the use of setuid or setgid bits allows you to give more privileges to a process. When a process executes another program, its effective uid is the same as the real uid. However, this behaviour doesn't allow a process which executes a special program to access a database if this is not accessible for him, or the database is accessible and he can access directly without the use of the special program; UNIX resolves this privilege problem by changing the effective uid with the setuid bit as shown in Figure - Use of setuid Bit.


$ id
uid=203(riche) gid=1(staff)
$ cat progc.c
main()
{
int fd;

if ((fd=open("database",0)) == -1)
perror("database");
else
printf("please, play\n");
}
$ make progc
cc -O progc.c -o progc
$ ls -l progc database
-rw------- 1 riche staff 45 Nov 16 15:49 database
-rwxr-x--- 1 riche staff 3515 Nov 16 16:24 progc
$ progc
please, play
$ su daniel
daniel's Password:
$ id
uid=205(daniel) gid=1(staff)
$ progc
database: Permission denied
$ exit
$ chmod u+s progc
$ ls -l progc
-rwsr-x--- 1 riche staff 3515 Nov 16 16:24 progc
$ su daniel
daniel's Password:
$ progc
please, play
$

Figure: Use of setuid Bit


**** NOTE: **** The setuid doesn't work with the script shells for security reasons.

System Check

When you install your operating system or an LPP, your software is composed of files with an integrity status. When you have used your operating system for a while, even if you audit security events as shown later, there may be some integrity problems.

You need check regularly if there are any unwanted setuid files. In this case, remove the setuid bit on these files. The reason why this setuid bit may be unwanted is it may allow superuser authority.

Operating System Check

The tool herein, allows you to memorize the main characteristics of security files in a check file, and periodically to do a static audit or to check the conformity of your file system with this check file. The set of security files plus some very important files, such as configuration commands for example, is called Trusted Computing Base (TCB). The check file is /etc/security/sysck.cfg. The command to check TCB is tcbck. You can check all the files described in the /etc/security/sysck.cfg file by means of the tree option or you can give a class of files or only some files (with whole path). In Figure - TCB Check File Examples are shown some stanzas of the /etc/security/sysck.cfg file.


# cat /etc/security/sysck.cfg
. . . . . . . . . .
/usr/bin/passwd:
owner = root
group = security
mode = TCB,SUID,r-xr-xr-x
type = FILE
oldpath = /bin/passwd
class = apply,inventory,bos.obj
size = 48358
checksum = "32388 48 "
. . . . . . . . . .
/etc/passwd:
owner = root
group = security
mode = TCB,664
type = FILE
size = VOLATILE
checksum = VOLATILE
class = apply,inventory,bos.obj, sec
. . . . . . . . . .
#

Figure: TCB Check File Examples

For each file, you have a stanza with many attributes. The owner, group, mode, and type must be present and not blank. You can test the integrity of the file with the checksum and the size.
Sometimes this has no sense (volatile value), such as the /etc/passwd file. tcbck verifies there is no modification for all the attributes, as shown in Figure - Example of Interactive Corrective Check.


# ls -l /etc/passwd
-rw-rw-rw- 1 root security 509 Nov 18 11:11 passwd
# tcbck -t sec
3001-023 The file /etc/passwd has the wrong file mode.
3001-075 Change the file modes for /etc/passwd? (yes, no) yes
# ls -l /etc/passwd
-rw-rw-r-- 1 root security 509 Nov 18 11:11 passwd
#

Figure: Example of Interactive Corrective Check

This operation may be done without confirmation and be executed in batch with the cron command (see the other options of tcbck).

Manipulating /etc/security/sysck.cfg

You can add some other stanzas in the /etc/security/sysck.cfg file with the tcbck command. In Figure - How to Add a File to Check, the new check you want to add in the /etc/security/sysck.cfg file is /home.


# ls -e newcheck
-rwsr-x--x+ 1 riche system 7 Nov 18 10:19 newcheck
# tcbck -a /home/riche/newcheck acl
# cat /etc/security/sysck.cfg
. . . . . . . . . .
/home/riche/newcheck:
owner = riche
group = system
mode = SUID,rw-r-x--x
type = FILE
acl = "attributes: SUID \nbase permissions\n owner(root): rw-\n grou
p system): r--\n others: ---\nextended permissions\n enabled\n specify
rw- u:daniel"
#

Figure: How to Add a File to Check

If you want to modify an existing stanza of /etc/security/sysck.cfg, you just have to run the sysck command with the name of the file to check followed by the new parameters you want to add.


# tcbck -a /home/riche/newcheck checksum class=privriche
# cat /etc/security/sysck.cfg
. . . . . . . . . .
/home/riche/newcheck:
. . . . . . . . . .
sum = "35965 1 "
class = privriche
#

Figure: How to Modify a Stanza

General Verification

You can use the ALL parameter with the tcbck command to verify the illegal setuid and setgid, the illegal link and some other security threats. This operation is quite long, and you should run it during the night.

Some other possibilities are:

Software Check

AIX allows the checking of LPPs integrity. At installation time, a description of the files included in the LPP allows the system to check the integrity of the LPP once installed, and the system keeps this information in the ODM database, in order to be able to check later the integrity of the files.

Later, you are able to check the integrity of the LPP with two commands: sysck and lppchk. You may want to update the system files from the ODM database, but you may also want to update the ODM database from the system files.

First Check at Installation Time

When an LPP is installed using the installp command, a file named <name_of_the_LPP>.inventory is restored from the installation image. It contains several stanzas that look similar to the /etc/security/sysck.cfg stanzas. This file is passed as input of a command that will update the ODM database at installation time. The ODM object class updated is inventory.

LPP Check from the System Files

Sometimes, it may happen you want ODM to be updated with some specific permissions you have defined in a personal file. Or you may want to update ODM from the current permissions of a file, because it seems better suited to your system use. In this case you want ODM to be overwritten with your personal specifications.

There are two ways to do this: sysck and lppchk commands. The following examples use the bosext1.csh.obj LPP. The file chosen is /usr/bin/csh. The first example shows the update with the sysck command, the second one with the lppchk command.


# export ODMDIR=/usr/lib/objrepos
# odmget -q"loc0 like /usr/bin/csh" inventory

inventory:
lpp_id = 398
. . . . . . . . . .
loc0 = "/usr/bin/csh"
. . . . . . . . . .
size = 349895
checksum = 25003
# cat localck.cfg
/usr/bin/csh:
owner = bin
group = bin
type = FILE
mode = rwxr-xr-x
size = 349895
checksum = "04961 342 "
# sysck -i -f localck.cfg /usr/bin/csh
The files for package /usr/bin/csh are being verified.
This may take several minutes, please wait.
# odmget -q"loc0 like /usr/bin/csh" inventory

inventory:
lpp_id = 398
. . . . . . . . . .
loc0 = "/usr/bin/csh"
. . . . . . . . . .
size = 349895
checksum = 4961
#

Figure: Updating ODM from a Superuser Defined Check File

In this example, the local.cfg file has been created copying a stanza added temporarily in the file /etc/security/sysck.cfg with the tcbck command with the -a flag (see Manipulating /etc/security/sysck.cfg).

Take care of the value of the ODMDIR variable. The inventory object class is under the /usr/lib/objrepos direcory in this case because the /usr/bin/csh file is under the /usr file system, that is the usr part of the LPP.


# export ODMDIR=/usr/lib/objrepos
# odmget -q"loc0 like /usr/bin/csh" inventory

inventory:
lpp_id = 398
. . . . . . . . . .
loc0 = "/usr/bin/csh"
. . . . . . . . . .
size = 349895
checksum = 25003
# lppchk -cu /usr/bin/csh
# odmget -q"loc0 like /usr/bin/csh" inventory

inventory:
lpp_id = 398
. . . . . . . . . .
loc0 = "/usr/bin/csh"
. . . . . . . . . .
size = 349895
checksum = 4961
#

Figure: Updating ODM from System Files

You can update the ODM database from any file of the system. In other words, you simply specify the name of the file with the lppchk command.

LPP Check From ODM

After a while, you may want to check the integrity of an LPP. In this case, you are not sure the permissions of the LPP files (the system files) have kept the correct initial permissions. You want to update the system files from the ODM database. The ODM database has recorded the information about these files at installation time.

The command you will use is the lppchk command. Here is an example using the same bosext1.csh.obj LPP.


# ls -l /usr/bin/csh
-rwxr-xr-x 1 bin bin 349895 Mar 28 11:49 /usr/bin/csh
# sum /usr/bin/csh
25003 342 /usr/bin/csh
. . . . . . . . . .
After a while
. . . . . . . . . .
# ls -l /usr/bin/csh
-r-xr-xr-x 1 root system 349895 Nov 18 16:30 /usr/bin/csh
# sum /usr/bin/csh
04961 342 /usr/bin/csh
# lppchk -f bosext1.csh.obj
# lppchk -c bosext1.csh.obj
lppchk: The checksum for file /usr/bin/csh is 4961,
expected value is 25003.
#

Figure: Checking an LPP from ODM

In this example, the lppchk is used with two different flags: the -f flag to check the file size integrity, and the -c flag to check the checksum of the file. In the example, the file has the same file size as before, but some inconstencies have appeared since the checksums are different.

Audit

The audit for an operating system is the same as surveillance video cameras in the company area. The first function is to capture all the relevant security events. The second function is the way to log audit. The third function is the way to keep logs in a secure place.

UNIX Audit

The UNIX audit tool is called syslog. syslog is used by many different programs such as the su command, the ftp command and also the nntpd daemon for news distribution.

syslogd Daemon Event Channels

Sixteen channels allow differentiation of the different audit classes. One class per command or daemon. Eight channels are available for specific usage. In Figure - Different Channels with syslogd Daemon, you can see the different classes you can find in the /etc/syslog.conf file.


kern            Kernel
user User level
mail Mail subsystem
daemon System daemons
auth Security or authorization
syslog syslogd daemon
lpr Line-printer subsystem
news News subsystem
uucp uucp subsystem
* All facilities.

Figure: Different Channels with syslogd Daemon

Network Approach of syslogd Daemon

The syslogd daemon has a network capacity to discuss among them. This allows you to dispatch your logs on different machines in a local network or to centralize all the logs of one class on one machine. Another very useful feature is the priority setting of a log, you have eight levels of audit gravity. See Figure - How to Dispatch your syslog Log for configuring syslog dispatch of the logs.


# <priority> is one of (from high to low):
# emerg/panic,alert,crit,err(or),warn(ing),notice,info,debug
# (meaning all messages of this priority or higher)
kern.warning /usr/lib/syslog/kern
# to all logged users
kern.crit *
user.debug /usr/lib/syslog/user
mail.info /usr/lib/syslog/mail
daemon.notice /usr/lib/syslog/daemon
auth.debug /usr/lib/syslog/auth
# to a printer
auth.notice /dev/tty1
syslog.info /dev/console
syslog.info /usr/lib/syslog/syslog
lpr.err /usr/lib/syslog/lpr
news.crit /usr/lib/syslog/news
uucp.notice /usr/lib/syslog/uucp
# to another machine, see the next section
local0.notice @log_machine
# to a terminal
local1.crit /dev/tty1
local1.debug /usr/lib/syslog/local2

Figure: How to Dispatch your syslog Log


**** NOTE: ****
The syslogd daemon uses the UDP/IP protocol that is not a safe protocol. If you log too much or if your network is overloaded, you risk to lose some packets. Also don't forget to alarm your syslogd daemon when you change the /etc/syslog.conf file by means of the kill -1 `cat /etc/syslog.pid` command.

How to Use the syslog Network Ability For Other Purposes

With the last eight channels and a very simple C program shown in Figure - C Program to Feed syslogd Daemon, you can use the syslog network ability to dispatch any other ASCII audit logs. This C program opens the channel called local0, sends a first start message, loops by reading an ASCII message. When a message arrives, it sends it to syslogd. If it receives an end of file message (^D), it exits from the loop and sends a last final message. In Figure - Example of Audit Output Using the Previous Program, you can see a sample using this program and the syslogd daemon.


/* File tosyslog0 */
#include <stdio.h>
#include <sys/syslog.h>

main()
{
int i;

openlog("audit",LOG_PID,LOG_LOCAL0);
syslog(LOG_WARNING,"Start of remote audit\n");
while (1)
{
char tampon[BUFSIZ];

gets(tampon);
if (feof(stdin))
break;
syslog(LOG_NOTICE,tampon);
}
syslog(LOG_WARNING,"End of remote audit\n");
closelog();
}

Figure: C Program to Feed syslogd Daemon

With the configuration of local0 in syslog.conf in Figure - How to Dispatch your syslog Log, you can see in Figure - Example of Audit Output Using the Previous Program the result of the C program described above.


Nov 17 13:38:49 audited_machine audit[16916]: Start of remote audit
. . . . . . . . . .
Nov 17 14:25:14 audited_machine audit[16916]: ....any audit messages
. . . . . . . . . .
Nov 17 15:41:37 audited_machine audit[16916]: End of remote audit

Figure: Example of Audit Output Using the Previous Program

AIX Audit

The AIX audit subsystem is specific and has many useful functions to help your security strategy. The AIX audit driver logs events in a binary way for efficient reasons. You have to transform binary to human readable log by using the auditprint command. However, keep in mind that audit too many events overloads your machine and besides you have no time to analyze the logs. To configure auditing on a machine is not a simple operation. You will need to scan frequently if the audit logs are usable and useful.

Configure your Audit Event Domain

There are three types of items that compose an event:
  1. Subject is generally a process.
  2. Action is a system call such as open a file, write a file or change a device status.
  3. Object is generally a file in the UNIX meaning.

The AIX operating system has a list of system calls that you can audit if you configure the audit. You find this list in /etc/security/audit/events file. If you develop your own application, you can implement new audit events. You have to add them in the /etc/security/audit/events file, as shown in Figure - How to Add a New Audit Event, but you also have to define a new event class (appli in the example) in the /etc/security/audit/config file as shown in Figure - How to Configure New Audit Classes. Then you use the auditlog system call to send your new event to the log. The /etc/security/audit/events file allows you to add a specific message and to display the value of a variable defined later in your C program.


# cat /etc/security/audit/events
auditpr:
. . . . . . . . . .
* fork()
PROC_Create = printf "forked child process %d"
. . . . . . . . . .
* applconf() your new event
APPLI_Environ = printf "buf: %s"
. . . . . . . . . .
#

Figure: How to Add a New Audit Event

In Figure - How to Add a New Audit Object you can see the /etc/security/audit/objects file, which contains a list of very important files such as the /etc/security/passwd file. AIX allows you to audit every read, write or execute access to any file you want. In the example in Figure - How to Add a New Audit Object, you can see an audit event defined for a private application password file.


# cat /etc/security/audit/events
. . . . . . . . . .
/etc/security/passwd:
r = "S_PASSWD_READ"
w = "S_PASSWD_WRITE"
. . . . . . . . . .
* your new object read event
/etc/security/applipwd:
r = "S_APPWD_READ"
. . . . . . . . . .
#

Figure: How to Add a New Audit Object

The configuration of audit is done in the /etc/security/audit/config file. All the events are dispatched in different classes. However, you can create your own classes, since an event may be in several different classes. See the example in Figure - How to Configure New Audit Classes.


# cat /etc/security/audit/config
. . . . . . . . . .
classes:
. . . . . . . . . .
proc = PROC_Create,PROC_Delete,PROC_Execute,. . . .
. . . . . . . . . .
appli = APPLI_Environ
apadm = APPLI_Environ, S_APPWD_READ
. . . . . . . . . .
. . . . . . . . . .
#

Figure: How to Configure New Audit Classes

Once you have defined your classes, you can configure the user and set classes for each user, see Figure - Audit User Configuration.


# cat /etc/security/audit/config
. . . . . . . . . .
users:
root = at,audit,dev, . . . . . . . .
riche = at,backup,cron,enque,restore,sendmail,apadm
daniel = user,appli
. . . . . . . . . .
#

Figure: Audit User Configuration

Configure your Log

When all these configurations are done, you have to configure the way to log your audit. You have two different ways:

  1. Use two predefined size files to alternately store the audit information.
  2. Use a circular buffer and process the output immediately.

You can use both at the same time. The first one is very easy to configure. You can use the defaults, see Figure - How to Configure an Audit Bin Log.


# cat /etc/security/audit/config
. . . . . . . . . .
start:
binmode = on
. . . . . . . . . .

bin:
trail = /etc/security/audit/trail
bin1 = /etc/security/audit/bin1
bin2 = /etc/security/audit/bin2
binsize = 10240
cmds = /etc/security/audit/bincmds
. . . . . . . . . .
# cat /etc/security/audit/bincmds
/etc/auditcat -p -o $trail $bin
#

Figure: How to Configure an Audit Bin Log

The second way to log is more complex because you dispatch your audit and process each different log. Figure - How to Configure an Audit Stream Log shows you how to:

Figure - Audit Logs Examples illustrates this by showing audit logs.


# cat /etc/security/audit/config
. . . . . . . . . .
start:
. . . . . . . . . .
streammode = on
. . . . . . . . . .
stream:
cmds = /etc/security/audit/streamcmds
. . . . . . . . . .
# cat /etc/security/audit/streamcmds
. . . . . . . . . .
/etc/auditstream -c connect | auditpr -t0 -h elrcRt > /dev/tty4 &
/etc/auditstream -c sem | /etc/auditselect -e "event==SEM_Op && command==sendma
il" | auditpr -v -t0 -h elrcRt > /etc/security/audit/print/sem &
/etc/auditstream -c tcpip | auditpr -v -t0 -h elrcRt | sed '/TCPIP_con.*inetd/N
;/nntp/d' > /etc/security/audit/print/tcpip &
/etc/auditstream -c dev | auditpr -v -t0 -h elrcRt | /etc/security/tosyslog0 &
. . . . . . . . . .
#

Figure: How to Configure an Audit Stream Log




$ cat /etc/security/audit/print/sem
. . . . . . . . . .
SEM_Op root root sendmail OK Fri Oct 01 23:26:24 1993
semid: 1
SEM_Op root root sendmail OK Fri Oct 01 23:26:24 1993
semid: 1
SEM_Op root root sendmail OK Fri Oct 01 23:56:23 1993
semid: 1
. . . . . . . . . .
$ cat /etc/security/audit/print/connect
. . . . . . . . . .
USER_Login riche riche tsm OK Thu Aug 26 09:54:40 1993
riche
USER_SU riche root su OK Thu Aug 26 09:55:04 1993
root
USER_Logout riche riche logout OK Thu Aug 26 09:56:08 1993
/dev/tty3
. . . . . . . . . .
$ cat /etc/security/audit/print/dev
. . . . . . . . . .
DEV_Change riche root chdev OK Thu Aug 26 09:55:51 1993
params = -l tty1 -a "login=delay "
. . . . . . . . . .
$

Figure: Audit Logs Examples

Periodical Management

Now your audit is set, you have to periodically check to see if it is working properly and to save weekly, for example, the different logs. In Figure - How to Keep the Audit Subsystem Running, you can see a way to verify if the audit is working and a way to restart it with the use of the cron subsystem.


# cat /etc/rc.include
. . . . . . . . . .
/etc/rc.audit
. . . . . . . . . .
# cat /etc/rc.audit
#!/bin/sh
cd /etc/security/audit/print
for i in at audit backup . . . . .
do
cat $i >> /etc/security/audit/histo/$i/`/etc/security/week`
done

audit start &
# cat /usr/spool/cron/crontabs/root
. . . . . . . . . .
11,31,51 * * * * if (audit query | sed 1q | grep -s "auditing off" > /dev/null )
then sh /etc/rc.audit;fi
. . . . . . . . . .
7,27,47 * * * * if (lssrc -s syslogd | grep -s "inoperative" > /dev/null ) then
startsrc -s syslogd;fi
. . . . . . . . . .
#

Figure: How to Keep the Audit Subsystem Running

In Figure - Audit Log of One Week Long, you can see a way to split your log files in a single week long file, using the week command and the cron subsystem. In Figure - week Program, you can see a way to implement the week number. This number is based on french week, which begins on monday. The double backup reason is to let the machine without audit during a minimal time and to not lose the shutdown event of audit. The nullfilter command is just a C program which eliminates the null characters.


# cat nullfilter.c
#include <stdio.h>

main()
{
char c;
while (1)
{
c=getchar();
if (feof(stdin))
exit(1);
if (c |= 0)
putchar(c);
}
}

Figure: nullfilter C Program

You can see the result in
Figure - Weekly Audit Archive Example.


# cat /usr/spool/cron/crontabs/root
. . . . . . . . . .
40 0 * * 6 /etc/security/audit/auditvidage
. . . . . . . . . .
# cat /etc/security/audit/vidage
#!/bin/sh
cd /etc/security/audit/print
for i in at audit backup . . . . .
do
cat $i >> /etc/security/histo/$i/`/etc/security/week`
cp /dev/null $i
done

audit shutdown

for i in at audit backup . . . . .
do
cat $i | /etc/nullfilter >> /etc/security/histo/$i/`/etc/security/week`
cp /dev/null $i
done
audit start &
#

Figure: Audit Log of One Week Long




# cat /etc/security/week
day=`date +'%j'`
jd=`date +'%w'`
monday=`expr $day - $jd`
week=`expr $monday / 7 `
reste=`expr $monday % 7`
if [ $reste -eq 0 ]
then
week=`expr $week + 1`
else
week=`expr $week + 2`
fi
echo $week
#

Figure: week Program




$ pwd
/etc/security/audit/histo
$ ls -C *
at:
10 13 16 19 21 24 27 3 32 35 38 40 43 46 52 9
11 14 17 2 22 25 28 30 33 36 39 41 44 5 53
12 15 18 20 23 26 29 31 34 37 4 42 45 51 6

audit:
10 13 16 19 21 24 27 3 32 35 38 40 43 46 52 9
11 14 17 2 22 25 28 30 33 36 39 41 44 5 53
12 15 18 20 23 26 29 31 34 37 4 42 45 51 6

backup:
10 13 16 19 21 24 27 3 32 35 38 40 43 46 52 9
11 14 17 2 22 25 28 30 33 36 39 41 44 5 53
12 15 18 20 23 26 29 31 34 37 4 42 45 51 6
. . . . . . . . . .
$

Figure: Weekly Audit Archive Example

Software Audit

Sometimes you want to know in which order a program reads its profile files, such as the csh shell. You may also want to know if a program writes any other files during its execution. In other words, you want to audit a software. With AIX, you can do that with the watch command. Its execution is not possible if the audit is started, because it uses the same driver as audit. In Figure - How to Use the watch Command, you can see how to run the watch command.


# watch -o output progc
please, play
** child process exiting: 13423
** all processes have exited
# cat output
***** WATCH *****
event login status time command
--------------- -------- ----------- ------------------------ ------------------
-------------
PROC_Execute riche OK Wed Nov 17 17:25:48 1993 progc
euid: 0 egid: 0 epriv: -1 name ./progc
***** WATCH *****
event login status time command
--------------- -------- ----------- ------------------------ ------------------
-------------
FILE_Open riche OK Wed Nov 17 17:25:48 1993 progc
flags: 0 mode: 0 fd: 4 filename database
***** WATCH *****
event login status time command
--------------- -------- ----------- ------------------------ ------------------
-------------
FILE_Write riche OK Wed Nov 17 17:25:48 1993 progc
file descriptor = 1
#

Figure: How to Use the watch Command

Security Export and Import

This section discusses the preservation of the file characteristics through different backup formats.

Backup Commands

The topic here is to look at the preservation of the file characteristics after a backup restoration, such as:

It is very important to be aware of these characteritics because you must avoid to restore an unwanted setuid bit and avoid a wrong backup due to some too long file pathnames. For example, if some pathnames are longer than 128 characters, don't use the cpio format. In the following table, you can see the default behaviour in the three first columns. All the backup commands are described:




Table: File Characteristic Preservation


**** NOTE: ****

fsl means file system limitation

For the tar command, the -m option during restoration uses the time of extraction as the modification time. The default is to preserve the modification time of the files dates to the restoration date

Using the cpio command with the -m option preserves the file-access and file-modification times

Using the pax command with the -p string option allows everything, such as to not retain file-modification times or to not preserve setuid bit

For the backup command, using the -M option during restoration sets the modification, access and update dates to the restoration date

With the dd command, as a whole file system is archived, all the characteristics are preserved

Remember the cp command loses ACL and setuid bit. In addition, it changes all the dates, but you can look at the -p option to preserve dates. See also the umask value which changes the default permissions and the ulimit value which truncates your files.