This section describes the tips and techniques of security tools available on AIX systems.
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.
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.
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.
This part discusses the access in the operating system and the first screen of a terminal.
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
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.
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.
# 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: "
The information you get during the login is also very important. You can get, for example:
The login information can be split in several parts:
For this last, you have to prevent the csh shell as shell login (see Shell).
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.
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.
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.
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.
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.
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.
The chfn command allows every user to change
the field called Gecos as shown in 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.
The /etc/security/user file contains many security user features:
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.
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.
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.
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.
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.
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.
The crontab, at, batch commands may be denied
or authorized to users. In the /var/adm/cron directory, you can create these
files:
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:
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.
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:
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. 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.
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.
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.
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 - Directly Test Your Rights shows you a little
script shell for your tests.
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.
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.
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.
Two attributes also exist in the access control list: setuid (SUID) and
setgid (SGID), as shown in Figure - Special Attributes.
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.
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.
This operation may be done without confirmation and be executed in batch
with the cron command (see the other options of tcbck).
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Once you have defined your classes, you can configure the user and set
classes for each user, see Figure - Audit User
Configuration.
When all these configurations are done, you have to configure the way to log
your audit. You have two different ways:
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.
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:
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.
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.
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:
The pax command allows you to restore files from tar and
cpio formats. In one of these cases, observe the respective format.
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.
# 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
# cat /etc/security/login.cfg
. . . . . . . . . .
/dev/console:
sak_enabled = true
. . . . . . . . . .
. . . . . . . . . .
# cat /etc/security/user
. . . . . . . . . .
riche:
tpath = on
. . . . . . . . . .
. . . . . . . . . .
#
Figure: How to Enable SAK
General User Configuration
This part discusses the configuration related to users and security.
User Security
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
Gecos Field
$ chfn riche
riche's current gecos:
"francois riche"
Change (yes) or (no)? > yes
To?>Francois Riche
$
Figure: Gecos Field Change
New Authentication 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
Users Configuration
Shell
# 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.
User Environment
# 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
$ 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
Timer Daemon Usage
Group Configuration
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
$ 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
The following Figure - Password Restrictions Example is
a password restrictions example.
**** NOTE: ****
The minimum length of a password on the system is minalpha + minother. The
maximum length of a password is eight characters.
# cat /etc/security/login.cfg
. . . . . . . . . .
pw_restrictions:
maxage = 24
minage = 1
minalpha = 5
minother = 2
mindiff = 3
maxrepeats = 2
. . . . . . . . . .
#
Figure: Password Restrictions Example
Table: Values for Password Restrictions
Password Change
$ ^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
UNIX 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
$ 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
$ 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
$ 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
$ 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.
$ 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
$ 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
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
Manipulating /etc/security/sysck.cfg
# 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
# 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
Software Check
First Check at Installation Time
LPP Check from the System Files
# 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
# 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
LPP Check From ODM
# 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
Audit
UNIX Audit
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
# <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
/* 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
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
Configure your Audit Event Domain
There are three types of items that compose an event:
# 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
# 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
# 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
# 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
# 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
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
# 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
# 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
Table: File Characteristic Preservation
**** NOTE: ****