Linux Solutions

Welcome to the tutorial guide. The tutorial will provide a user with advise and guidance on system logging with socklog.

As of Annvix 1.1-RELEASE the socklog program has been provided as an alternative to syslogd and klogd. As of 2.0-RELEASE, socklog is the default logger installed and the sysklogd package has been removed.

A user should note that socklog is an alternative secure system logger with a lot of features. It uses the default svlogd program to handle the actual logging; socklog itself just listens to sockets, be they UNIX sockets, TCP ports, or UDP ports. Because of this, socklog is very extensible and offers features that syslogd can’t, including:

remote logging via TCP
receiving remote logs via TCP
automatic log rotation

Let’s have a look at log directories versus log files.

Log directories vs. log files
The socklog package in Annvix comes with three default services: socklog-unix, socklog-klog, and socklog-rklog. The first service listens to the standard /dev/log socket that is used by applications to send messages to the syslog. The second receives messages from /proc/kmsg (normally klogd would receive these messages and relay them to the syslog); the socklog-klog service does not relay these messages to the system logger but manages the logs itself. Likewise, socklog-rklog receives messages from /proc/rsbac-info/rmsg which are RSBAC-related kernel messages (NOTE, as of RSBAC 1.2.5.1 it does not look like the configuration option CONFIG_RSBAC_RMSG_EXCL works so messages from RSBAC still end up being sent via /proc/kmsg in addition to /proc/rsbac-info/rkmsg).
As a result, instead of kernel logs ending up in /var/log/kernel (and in /var/log/messages, the kernel logs end up in the /var/log/system/kmsg directory, with the current file being the most recent logfile. The RSBAC kernel logs end up in /var/log/system/rkmsg.

A user should note that normal logfiles that would normally populate /var/log (such as auth.log, boot.log, messages, and so forth are no longer used and can be safely removed from the system once socklog is installed. Instead, the default socklog configuration is to log the following facilities to the following log directories:

all logs: /var/log/system/all
auth.* and authpriv.*: /var/log/system/auth
local7.*: /var/log/system/boot
cron.*: /var/log/system/cron
daemon.*: /var/log/system/daemon
*.debug: /var/log/system/debug
ftp.*: /var/log/system/ftp
kern.*: /var/log/system/kern
local.*: /var/log/system/local
mail.*: /var/log/system/mail
*.info (excluding mail.info, news.info, authpriv.info and kern.info): /var/log/system/messages
news.*: /var/log/system/news
syslog.*: /var/log/system/syslog
user.*: /var/log/system/user

Within each directory is the current file which is the latest log and other files using a TAI64 timestamp that indicate the date of rotation (i.e. @4000000043ed4a8b03f03b6c.s). Also, within each file is a config file which tells svlogd what to log; for instance the /var/log/system/messages/config file looks like:
-*.*
+*.info*
-mail.*
-news.*
-authpriv.*
-kern.*

Order is important; here everything is deselected first, then all *.info priorities are added and finally, selectively, various facilities are removed that are not desired to be logged there.

Customizing socklog
The default socklog configuration is adequate for most people with a single-log system (i.e. not receiving remote logs nor sending them). However, it is desirable to be able to send (and receive) logs to other systems. Even adding new facilities or manipulating logging on a single system may be desirable.

Configuring svlogd
svlogd is told what directories to read config files from via the logging runscript for a service, so for socklog-unix this would be in the file /var/service/socklog-unix/log/run. This file contains, by default:
#!/bin/execlineb

/bin/cd /var/log/system
/sbin/chpst -u syslogd /sbin/svlogd
/var/log/system/all
/var/log/system/auth
/var/log/system/boot
/var/log/system/cron
/var/log/system/daemon
/var/log/system/debug
/var/log/system/ftp
/var/log/system/kern
/var/log/system/local
/var/log/system/mail
/var/log/system/messages
/var/log/system/news
/var/log/system/syslog
/var/log/system/user

As can be seen here, arguments to svlogd are the full paths to directories containing config files (which will also in turn contain log files). To, for instance, log openldap messages (which, when the openldap-server package is installed modifies /etc/syslog.conf to send local0.* logs to /var/log/ldap/ldap.log), a user would add /var/log/system/ldap to the end of the directory list in the run script.

A user can now create the /var/log/system/ldap directory:
# mkdir /var/log/system/ldap
# chmod 770 /var/log/system/ldap
# chown root:syslogd /var/log/system/ldap
Then create the /var/log/system/ldap/config file, which would contain:
-*
+local0.*

If user wants to restart svlogd, then he/she needs to send it a HUP using runsvctrl: (/sbin/runsvctrl h /service/socklog-unix/log). Now svlogd has been restarted and will begin to log the newly added ldap configuration.

Logging to a remote server using UDP
It should be noted that while socklog supports receiving logs via UDP, using UDP as a transmission medium should be avoided if at all possible because UDP is both unreliable and insecure. If at all possible, use TCP to transmit log data (if the sending/receiving servers support it, i.e. using socklog or syslog-ng or another system logger than can send/receive logs via TCP).

If a user wnats to instruct svlogd to log to a remote server over UDP (for instance, to a remote syslogd server), then he/she has to create a new configuration directory and file as indicated above but use the directory /var/log/system/remote with the contens of /var/log/system/remote/config being:
+*.*
s9999
n2
U192.168.1.2:514

Then a user has to restart svlogd . This will instruct svlogd to send what it receives to the remote system (192.168.1.2) on port 514 using the UDP protocol. This also tells svlogd to rotate the log every 10KB (triggering the sending of the log to the remote host) and tells svlogd to maintain a maximum number of 2 old log files (in the case of transmission failure).

Please note that using “U” here tells svlogd not to maintain a local copy of the logs (although any errors are logged to current); instead it will send the log files as soon as it receives them. A user can send UDP logs onto another logging directory (say all), by using “u” instead of “U” (read the svlogd(8) manpage for more info). For ease of configuration, having a separate logging directory designated as the “to-remote” log may be a better idea than modifying other configurations.

Receiving logs from a remote server using UDP
Install the socklog-remote package; this package comes with default run scripts to receive TCP- and UDP-based log messages. Before starting socklog-udp, edit the /var/service/socklog-unix/log/run as by default it receives all logs to /var/log/system/remote/all-udp and it is sometimes a good idea to further split the logs based on the sender’s IP address. The resulting run script may look like:
#!/bin/execlineb

/bin/cd /var/log/system/remote
/sbin/chpst -u syslogd /sbin/svlogd
/var/log/system/remote/all-udp
/var/log/system/remote/192.168.1.12
The first run script tells socklog to listen to port 514 on all hosts with the inet protocol UDP.
By default, socklog-udp listens on UDP port 514 (the default syslog port) which can be modified by changing /var/service/socklog-udp/env/PORT. A user can also specify what IP address to bind by creating /var/service/socklog-udp/env/IP with the IP address a user wants the service to bind to (the default is all).

The received logs are printed to STDOUT (prefixed with the sender’s IP address), so the log/run script handles the actual logging. In this case, it will log all received UDP syslog messages to /var/log/system/remote/all and will log messages from the sender IP 192.168.1.12 to /var/log/system/remote/192.168.1.12 via the following config files:
The /var/log/system/remote/all-udp/config file, by default, looks like:
+*.*
and the /var/log/system/remote/192.168.1.12/config file should look like:
-*
+192.168.1.12:*

A user can add subsequent IP-based directories (i.e. perhaps a /var/log/system/remote/192.168.1.13 directory) to handle logging for more than one sending IP. If separating logs per host is not a concern, do away with the IP-based logging directories. The rationale behind an “all” directory and IP-based directories is to ease separation of logs per host (something syslog cannot easily do) and also provide a “master” log that can be used by tools such as swatch.

If a user wants to add this new service, then he/she can use srv –add socklog-udp (if a user can make the appropriate changes in /var/service/socklog-udp before adding the service, a user can save himself/herself a restart). A user should remember to send the socklog-udp/log service a KILL signal if configuration changes are made; this can be accomplished with either runsvctrl k /service/socklog-udp/log or srv -f –restart socklog-udp/log.

Logging to a remote server using TCP
When logging to a remote server, a user can choose to send the logs to the remote server instead of keeping them on the system, or a user can log both to the system and to the remote server. Note that this will not pick up kernel logs (which the socklog-klog service monitors), although a user can do a similar type of configuration for socklog-klog or a duplicate service to handle it.
If a user wants to log to a remote system via TCP instead of logging locally, change /service/socklog-unix/log/run to look like:
#!/bin/execlineb

/bin/cd /var/log/system
/sbin/chpst -u syslogd /sbin/svlogd
/var/log/system/all
Next, edit the /var/log/system/all/config file which should look similar to:
+*.*
s2048
n20
!tryto -pv nc -q 1 192.168.1.2 12000

This instructs svlog to set the log size to 2KB and to keep a maximum of 20 log files. The “!tryto” indicates using the tryto program as a pre-processor; svlogd will run tryto with the specified arguments before rotating the log. The “-pv” option tells tryto that it is being used as a svlogd pre-processor and to be verbose about what it is doing. The next option tells tryto to execute nc (netcat); what it does is feed it’s STDIN to nc as STDIN. In this case, nc is told to send it’s STDIN to the IP address 192.168.1.2 on port 12000. Change the IP address and port number to suit a user configuration. A user will need to install the nc package. The “-q 1″ option to nc tells it to wait 1 second after an EOF is detected; if a user doesn’t include this option nc will continue to hang around long after it should.

Please note that depending on the system, 2KB chunks may be too fast or too slow so a user should determine how often they’re sent to the remote system before settling on a particular size. What happens here is that on every rotation, nc is being used to send the contents of current; in other words if it takes three weeks to fill up 4KB of content, it will be three weeks before the log is transmitted.

If a user wants to mantain system logs and log remotely, change /service/socklog-unix/log/run and add another directory to the end of the directory list, perhaps /var/log/system/toremote, then create the directory (making sure it is owned root:syslogd and mode 0770) with a config file with contents identical to what was previously noted:
+*.*
s2048
n20
!tryto -pv nc 192.168.1.2 12000

This acts the same as the previous configuration, however here we are adding another logging directory who’s sole job is to feed received logs to the remote system, without interfering with what is locally logged.

Receiving logs from a remote server using TCP
As with receiving logs over UDP, install the socklog-remote package to get the default run scripts, for this service we’re interested in socklog-tcp. By default the service uses tcpsvd to listen to the local TCP port (5140 by default but this can be changed by modifying /var/service/socklog-tcp/env/PORT). When connections are received on this port, the connection is passed off to socklog which is using the ucspi connection method. A user can also specify what IP address to bind to (if a user wants to be explicit) by creating /var/service/socklog-tcp/env/IP with the IP address a user wants the service to bind to (the default is all).

Handling the logs is very similar to handling incoming UDP logs. Modify the /var/service/socklog-tcp/log/run script to look like the following (to again allow for per-IP directory logging; the default simply logs all TCP-based logs to /var/log/system/remote/all-tcp):
#!/bin/execlineb

/bin/cd /var/log/system/remote
/sbin/chpst -u syslogd /sbin/svlogd
/var/log/system/remote/all-tcp
/var/log/system/remote/192.168.1.12

The received logs are printed to STDOUT (via socklog and prefixed with the sender’s IP address), so the log/run script handles the actual logging. In this case, it will log all received TCP syslog messages to /var/log/system/remote/all-tcp and will log messages from the sender IP 192.168.1.12 to /var/log/system/remote/192.168.1.12 via the following config files:
The /var/log/system/remote/all-tcp/config file looks like:
+*.*
and the /var/log/system/remote/192.168.1.12/config file should look like:
-*
+192.168.1.12:*

Add subsequent IP-based directories (i.e. perhaps a /var/log/system/remote/192.168.1.13 directory) to handle logging for more than one sending IP. If separating logs per host is not a concern, do away with the IP-based logging directories. The rationale behind an “all” directory and IP-based directories is to ease separation of logs per host (something syslog cannot easily do) and also provide a “master” log that can be used by tools such as swatch.

If a user wants to add this new service, then he/she should use srv –add socklog-tcp (if a user can make the appropriate changes in /var/service/socklog-tcp before adding the service, a user can save himself/herself a restart).

A user should remember to send the socklog-tcp/log service a KILL signal if configuration changes are made; this can be accomplished with either runsvctrl k /service/socklog-tcp/log or srv -f –restart socklog-tcp/log.

If a user has followed this tutorial guide then he/she would have learnt about system logging with socklog.

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on using the tcb shadow alternative. Please note that the tcb package is a replacement for the traditional method of storing encrypted passwords in the /etc/shadow file.

There are benefits of using tcb. These are provided below:
By using tcb, each user gains access to their shadow password, and their shadow password only. There is no need for a setuid root passwd program.
Also, by using tcb, it uses blowfish passwords by default, rather than the more insecure md5 password.
Please note that for new users who install Annvix 2.0 do not require anything to begin using tcb; as of 2.0-CURRENT, tcb and blowfish passwords are the default. Users upgrading from a previous version of Annvix will transparently be using tcb after executing the upgrade script that upgrades 1.2 to 2.0.

Before the Upgrade
Before a user upgrades to 2.0, it is recommended to know if there are two consoles or ssh sessions open to the system that a user is upgrading. These two consoles are:
a regular user,
the other as root.
If a user doesn’t do this then there is a risk for a user to completely lock himself/herself out of the system until the upgrade is complete.
Another way of upgrading the system is by using the upgrade script.
Converting /etc/shadow to the tcb format
A user should note that there are various steps to conver /etc/shadow to the tcb format.
A user has to to convert the existing shadow password entries into individual tcb entries. Please note that the tcb structure for storing passwords does not use a single file, like /etc/shadow but instead a directory structure like /etc/tcb/joe where joe is the user and joe’s shadow password is stored in the file /etc/tcb/joe/shadow. A user can do this by executing the /sbin/tcb_convert program as root.
The resulting directory structure of /etc/tcb will look like this:
# ls -dl /etc/tcb
drwx–x— 30 root shadow 4096 Jul 6 21:23 /etc/tcb/
# ls -l /etc/tcb/
total 0
drwx–s— 2 adm auth 19 Jul 6 21:23 adm/
drwx–s— 2 apache auth 19 Jul 6 21:23 apache/
drwx–s— 2 bin auth 19 Jul 6 21:23 bin/
drwx–s— 2 builder auth 19 Jul 6 21:23 builder/
drwx–s— 2 daemon auth 19 Jul 6 21:23 daemon/
drwx–s— 2 halt auth 19 Jul 6 21:23 halt/
drwx–s— 2 joe auth 19 Jul 6 21:23 joe/
drwx–s— 2 logger auth 19 Jul 6 21:23 logger/
drwx–s— 2 lp auth 19 Jul 6 21:23 lp/
drwx–s— 2 mail auth 19 Jul 6 21:23 mail/
drwx–s— 2 mysql auth 19 Jul 6 21:23 mysql/
drwx–s— 2 news auth 19 Jul 6 21:23 news/
drwx–s— 2 nobody auth 19 Jul 6 21:23 nobody/
drwx–s— 2 operator auth 19 Jul 6 21:23 operator/
drwx–s— 2 postfix auth 19 Jul 6 21:23 postfix/
drwx–s— 2 root auth 19 Jul 6 21:23 root/
drwx–s— 2 rpm auth 19 Jul 6 21:23 rpm/
drwx–s— 2 rsbadmin auth 19 Jul 6 21:23 rsbadmin/
drwx–s— 2 rsbdata auth 19 Jul 6 21:23 rsbdata/
drwx–s— 2 rsbtpmgr auth 19 Jul 6 21:23 rsbtpmgr/
drwx–s— 2 shutdown auth 19 Jul 6 21:23 shutdown/
drwx–s— 2 snort auth 19 Jul 6 21:23 snort/
drwx–s— 2 sshd auth 19 Jul 6 21:23 sshd/
drwx–s— 2 svn auth 19 Jul 6 21:23 svn/
drwx–s— 2 sync auth 19 Jul 6 21:23 sync/
drwx–s— 2 syslogd auth 19 Jul 6 21:23 syslogd/
drwx–s— 2 vcsa auth 19 Jul 6 21:23 vcsa/
# ls -l /etc/tcb/joe/
total 4
-rw-r—– 1 joe auth 58 Jul 6 21:23 shadow
# cat /etc/tcb/joe/shadow
joe:$2a$08$abcdefghijklmnopqrstuuz29TNT43FrbrkSgusq0SUVtGQkhH2mm:13112:0:99999:7:::

Lookups with tcb (/etc/nsswitch.conf)
When the new glibc package was installed, it either modified the existing nsswitch.conf file to use tcb shadow entries or, if a user modified it (i.e. to use LDAP) then it created a new file: /etc/nsswitch.conf.rpmnew. This file contains the default entry of using tcb for shadow passwords. A user will need to copy this file over the previous file or a user will need to manually edit /etc/nsswitch.conf by changing:
shadow: files nisplus nis
to:
shadow: tcb nisplus nis
After a user has made this change, the system will use nss_tcb to do lookups for shadow passwords via the tcb files.
If a user is using LDAP for lookups, then he/she can simply replace “files” with “tcb” on the shadow line, be it before or after the “ldap” entry. A user can then test it by executing, as root getent shadow. In this way, a user will be able to get a list of all the shadow entries for all the users on the system. When a user verifies that this works, a user should rename /etc/shadow to /etc/shadow.bk and test it again. If this continues to work, a user should delete the moved file and the /etc/shadow- backup file.

Authenticating with tcb (/etc/pam.d/system-auth)
If a user wants to actually authenticate against tcb, then a user should pam_tcb installed; the upgrade will have done this for the user. As with nsswitch.conf, if a user has made no changes to the default /etc/pam.d/system-auth file, the new pam will replace the file with calls to pam_tcb instead of pam_unix. Regardless of this change, because pam_tcb understands shadow passwords, if a user chooses not to convet to tcb, the existing shadow entries will continue to be read. If a user has followed the instructions up to this point and has deleted the old shadow files, then the system will be using tcb immediately.

If a user has made changes to system-auth, then he/she will need to merge back the changes from the newly-created system-auth.rpmnew file. A user should note that the changes were to switch from pam_unix to pam_tcb, and also switch from pam_cracklib to pam_passwdqc. A user should change the pam_cracklib entries because pam_cracklib is no longer shipped with Annvix. A user should leave pam_unix as is, because a symlink for compatibility was created, but it is not advised.
The new system-auth file is displayed below:

#%PAM-1.0
# $Id: system-auth.pamd 5743 2006-07-04 04:49:31Z vdanen $

auth required pam_env.so
auth required pam_tcb.so shadow fork nullok prefix=$2a$ count=8

account required pam_tcb.so shadow fork

password required pam_passwdqc.so min=disabled,12,8,6,5 max=40 passphrase=3 match=4 similar=deny \
random=42 enforce=everyone retry=3
password required pam_tcb.so use_authtok shadow write_to=tcb fork nullok prefix=$2a$ count=8

session required pam_limits.so
session required pam_tcb.so
Some good points to note are provided below:
If a user wants to continue using md5 passwords then he/she can do it bymodifying the password entry to remove “prefix=$2a$ count=8″ and replace it with “md5″
If a user wants to continue using /etc/shadow instead of tcb files, then he/she should remove the “write_to=tcb” portion of the password entry
After a user has comleted the pam modification, then he/she should attempt to use sudo from the unprivileged account to become root.

A user should use the passwd program to change his/her password. This will test to if pam_tcb is properly reading from and writing to the tcb files and also ensure that the password is stored as a blowcrypt-based password rather than the undesirable md5-based password.

tcb and LDAP together
A user can use a /etc/pam.d/system-auth file like the following to use both tcb and LDAP-based logins together. If the system is setup correctly to permit users to change their LDAP password with the passwd command, then he/she can continue to permit password changes. It is good to note that passwords will be stored in the LDAP database with the pre-existing settings. LDAP does not understand or use blowfish passwords.
#%PAM-1.0
# $Id: system-auth.pamd 5743 2006-07-04 04:49:31Z vdanen $

auth required pam_env.so
auth sufficient pam_tcb.so shadow fork nullok prefix=$2a$ count=8
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

account sufficient pam_tcb.so shadow fork
account sufficient pam_ldap.so
account required pam_deny.so

password required pam_passwdqc.so min=disabled,12,8,6,5 max=40 passphrase=3 match=4 similar=deny \
random=42 enforce=everyone retry=3
password sufficient pam_tcb.so use_authtok shadow write_to=tcb fork nullok prefix=$2a$ count=8
password sufficient pam_ldap.so use_authtok
password required pam_deny.so

session required pam_limits.so
session sufficient pam_tcb.so
session sufficient pam_ldap.so
session required pam_deny.so
As well, /etc/nsswitch.conf will look like:
passwd: files ldap nisplus nis
shadow: tcb ldap nisplus nis
group: files ldap nisplus nis
A user should set “tcb” before “ldap” on the shadow entry.
Tweaking /etc/login.defs
If a user has changed /etc/login.defs then he/she will need to manually merge in the changes from the login.defs.rpmnew file. Some new options are provided below:
#
# The password hashing method and iteration count to use for group
# passwords that may be set with gpasswd(1).
#
CRYPT_PREFIX $2a$
CRYPT_ROUNDS 8

#
# Whether to use tcb password shadowing scheme.
#
USE_TCB yes

#
# Whether newly created tcb-style shadow files should be readable by
# group “auth”.
#
TCB_AUTH_GROUP yes

#
# Whether useradd should create symlinks rather than directories under
# /etc/tcb for newly created accounts with UIDs over 1000. See tcb(5)
# for information on why this may be needed.
#
TCB_SYMLINKS no
If a user doesn’t want tcb support and has not enabled it then he/she will need to disable USE_TCB and if a user doesn’t want blowcrypt passwords, then he/she should change CRYPT_PREFIX to “$1$” and comment outCRYPT_ROUNDS.

If a user followed this tutorial guide then he/she would have learnt about using the tcb shadow alternative.

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on configuring AppArmor.

Before we start the process of configuring AppArmor, we will have a look at what is AppArmor.
AppArmor
AppArmor is a user friendly, easy to use and effective Linux security system that makes use of the Linux 2.6 kernel’s Linux Security Modules (LSM) interface. AppArmor protects the system and applications from other applications that may be exploited by an attacker. AppArmor does not require extensive policies that affect every running system. AppArmor can easily be configured to contain only specific applications. Annvix also includes RSBAC for full Mandatory Access Control if required, however AppArmor makes an excellent stop-gap for a number of network-facing applications and services that require additional protection without impeding those applications that do not.

How to start AppArmor?
Annvix installs AppArmor including apparmor-profiles, apparmor-utils, and apparmor-parser. There is an initscript that starts and stops AppArmor support on Annvix. This initscript can be enabled or disabled by using following command:
# service apparmor start
and
# service apparmor stop
A user will note that on the first boot of Annvix, AppArmor is started, using the default profiles, and ready to begin protecting users system.

AppArmor Configuration Files
The AppArmor’s configuration files can be found in the /etc/apparmor.d directory. The files contained here take the form of full system path names, so /usr/bin/exim would have a profile named /etc/apparmor.d/usr.bin.exim.
Configuration files for the operation of AppArmor itself are contained in the /etc/apparmor directory. In the /etc/apparmor/profiles/extras directory are a number of profile files that can be experimented with and/or used but are not enabled by default for various reasons.

AppArmor Profile
An AppArmor profile consists of a file in the /etc/apparmor.d directory with a filename similar to the application’s path name, such as /usr/bin/exim would become /etc/apparmor.d/usr.bin.exim.
An example profile for /sbin/klogd would be named /etc/apparmor.d/sbin.klogd and contain:
# $Id: sbin.klogd 12 2006-04-12 21:35:41Z steve-beattie $
# ——————————————————————
#
# Copyright (C) 2002-2005 Novell/SUSE
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public
# License published by the Free Software Foundation.
#
# ——————————————————————

#include

/sbin/klogd {
#include

capability sys_admin,

/boot/System.map* r,
/proc/kmsg r,
/sbin/klogd rix,
/var/log/boot.msg rwl,
/var/run/klogd.pid rwl,
}
A user can see that the lines beginning with ‘#’ are comments, the exception being #include statements.

The application’s profile begins with the full name and path of the program to contain. Please note that this is one fundamental difference between AppArmor and other solutions like RSBAC and SELinux. AppArmor performs path-based operations on programs where as RSBAC and SELinux are inode-based. If a user has a hardlink copy of the file, the hardlink would not be protected without it’s own profile.

The curly braces ({}) serve as a container for include statements to other profiles and also for path and capability entries. The capability entry statements enable each of the 29 POSIX.1e draft capabilities. Please note that the path-based entries indicate access rights for the program being contained. In this case, the /boot/System.map* files are available for reading, /proc/kmsg is available for reading, /sbin/klogd (the program itself) is available for reading and executing, /var/log/boot.msg is available for reading, writing and linking, and /var/run/klogd.pid is also available for reading, writing, and linking. Path entries take the form “/path/to/file [mode]”. The path entry can be the full path and filename or can be a path using regular expression globbing.

When an application has a profile, only those files, modes, and POSIX capabilities specified can be used by the application. These restrictions are in addition to native ACLs (so, for instance, if a program does not have access to /etc/passwd, permitting access in the profile will not magically grant access to the file).

File Permission Access Modes
The following is a list of file permission access modes that AppArmor uses:
r - read mode
w - write mode
px - discrete profile execute mode
ux - unconstrained execute mode
ix - inherit execute mode
l - link mode
Read mode allows the program to have read access to the resource. Read access is required for shell scripts and other interpreted content and determines if an executing process can core dump or be attached to with ptrace(2). Write mode allows the program to have write access to the resource. This must be available for files to be unlinked (removed).

Discrete profile execute mode is a mode that requires that a discrete security profile is defined for a resource executed at an AppArmor domain transition. If no profile is defined, access is denied. This mode is incompatible with inherit and unconstrained execute entries. Unconstrained execute mode is a mode that allows the program to execute a resource without any AppArmor profile being applied to the executed resource. This mode is incompatible with inherit and discrete execute entries.
The unconstrained execute mode is useful when a confined program needs to be able to perform a privileged operation, such as rebooting the machine.

Inherit execute mode is a mode that prevents the normal AppArmor domain transition on execve(2) when the profiled application executes the resource. Instead, the executed resource inherits the constraints of the current profile. This mode is incompatible with the discrete and unconstrained execute entries.
The inherit execute mode is useful when a confined program needs to call another confined program without gaining the permissions of the target’s profile or losing the permissions of the current profile.
Link mode is a mode that grants access to symlinks and hardlinks the privileges to unlink (or delete) files. When a link is created, the file that is linked to must have the same access permissions as the link created (with the exception that the destination does not have to have link access).

Using genprof to Profile an Application
A user will note that genprof is the utility used to generate profiles for applictions. Genprof is the scan /var/log/system/audit/current for events, which is provided below:

type=APPARMOR msg=audit(1182207408.754:34): PERMITTING access to capability ’setgid’ (ntpd(18040) profile /usr/sbin/ntpd active /usr/sbin/ntpd)
type=APPARMOR msg=audit(1182207408.754:35): PERMITTING access to capability ’setuid’ (ntpd(18040) profile /usr/sbin/ntpd active /usr/sbin/ntpd)
type=APPARMOR msg=audit(1182207408.754:36): PERMITTING r access to /etc/hosts (ntpd(18039) profile /usr/sbin/ntpd active /usr/sbin/ntpd).

If a capability is requested but not available for the program, the audit log will note this. genprof takes these and allows a user to build profiles based on this information. For instance, to profile /usr/sbin/ntpd, a user can use following:
# genprof /usr/sbin/ntpd

A user can in another terminal, execute /usr/sbin/ntpd and let it run. When it has run sufficiently long enough for it to do most of what it would do, press S in genprof to scan the audit log for events. It will notify user as to what events took place, and a user can determine whether or not to allow the events. This can be done by creating a new profile and placing it into “complain” mode. After a user has done this, he/she can then press F to finish, and the new profile is written and placed into “enforce” mode.

If a user has followed this tutorial guide then he would have learnt about Configuring AppArmor.

Welcome to the tutorial guide. The tutorial will provide a user with advise and guidance on how to manage supervised services. Please note that Annvix uses a different means of managing daemons and services. Initscripts is a means of starting and stopping of system services. They are called as:
# /etc/init.d/script start
Or:
# service script start

There are some weaknesses associated with these initscripts. The initscripts are big and bulky and, more often than not, unnecessarily bloated. This makes them slow to start services. The problems can occur if the administrators restarts services. This will inherit variables from the current user’s shell environment. If a service stops then the service stays down. This may be good if a particular service is being configured, but can be very problematic on systems that require high availability.
Please note that a wrapper was written to handle talking to services. The wrapper script is called srv.

How to use srv?
It is good to know more about srv. srv controls services in a same way as service. If a user installs a daemon service on Annvix, it does not automatically start for a user. A user needs to explicitly enable the service before it will ever start. By default, openssh-server is installed on Annvix but, as with all daemon services, it is not started by default or even made available by default. If a user wants to obtain a list of available services, then he/she should execute following:
# srv –list

service status pid started
————————————————————-
crond up 3397 02/02/2007 12:03:45 AM
crond/log up 3366 02/02/2007 12:03:45 AM
mingetty-tty1 up 5785 02/02/2007 12:10:41 AM
mingetty-tty2 up 3302 02/02/2007 12:03:44 AM
mingetty-tty3 up 3399 02/02/2007 12:03:45 AM
mingetty-tty4 up 3332 02/02/2007 12:03:44 AM
mingetty-tty5 up 3331 02/02/2007 12:03:44 AM
mingetty-tty6 up 3362 02/02/2007 12:03:46 AM
socklog-klog up 3409 02/02/2007 12:03:45 AM
socklog-klog/log up 3408 02/02/2007 12:03:45 AM
socklog-rklog - - -
socklog-rklog/log - - -
socklog-unix up 3444 02/02/2007 12:03:45 AM
socklog-unix/log up 3443 02/02/2007 12:03:45 AM
sshd - - -
sshd/log - - -

Please note that only crond, socklog-klog, socklog-unix, and the mingetty services are available and running. These services are the only ones to start “out of the box”. A user will also be able to view that sshd is installed, but is not available. If a user wants to enable sshd, then he/she should execute following code:
# srv –add sshd
Adding service ’sshd’: …….done
# srv –list

service status pid started
————————————————————-
crond up 3397 02/02/2007 12:03:45 AM
crond/log up 3366 02/02/2007 12:03:45 AM
mingetty-tty1 up 5785 02/02/2007 12:10:41 AM
mingetty-tty2 up 3302 02/02/2007 12:03:44 AM
mingetty-tty3 up 3399 02/02/2007 12:03:45 AM
mingetty-tty4 up 3332 02/02/2007 12:03:44 AM
mingetty-tty5 up 3331 02/02/2007 12:03:44 AM
mingetty-tty6 up 3362 02/02/2007 12:03:46 AM
socklog-klog up 3409 02/02/2007 12:03:45 AM
socklog-klog/log up 3408 02/02/2007 12:03:45 AM
socklog-rklog - - -
socklog-rklog/log - - -
socklog-unix up 3444 02/02/2007 12:03:45 AM
socklog-unix/log up 3443 02/02/2007 12:03:45 AM
sshd up 5644 02/10/2007 10:25:02 AM
sshd/log up 9177 02/10/2007 10:25:55 AM
A user can note that sshd is available and running.
Retaining Status Across Reboots
If a user wants to turn down by using following code:
# srv –down sshd
then on the next reboot, sshd will stay down.
srv Options
The best source of information on srv is the manpage. Following options will summarise all the command that a user can pass to srv:
–help - lists all available commands
–list | -l ([service]) / - lists all available services or just the named service
–info | -i [service] - displays verbose information on a single service
–add | -a [service] - adds a service to /service and starts it
–del | -z [service] - removes a service from /service, stopping it first
–up | -u [service] - starts the named service
–down | -d [service] - stops the named service; on a reboot it will remain down
–restart | -r [service] - stops then starts the named service
–reload | -h [service] - restarts a service by sending it a HUP signal
The –add and –del commands are similar to those from chkconfig. The –list command is similar to chkconfig –list.
The –up and –down commands work similar to the service commands “start” and “stop” for initscripts.
The –list command will show what services are installed, which are available to be started, and what their status is by showing a “-” (available but not in /service), “up” (running), or “down” (not running).
The –info command gives extended status information on a particular service. If a user wants to check the status of sshd, then a user should use:
# srv –info sshd
Service: sshd
————————————————
Installed: Thu 01 Feb 2007 11:19:45 PM MST
RPM: openssh-server-4.5p1-6584avx
RPM Desc: OpenSSH Secure Shell protocol server (sshd)
————————————————
Managed: Yes
Status: Up
Pid: 3376
Processes:
tcpsvd(3376)-+-sshd(24424)—sshd(24426)—sh(24427)—screen(24428)—zsh(24429)
`-sshd(8785)—sshd(8787)—zsh(8788)—su(8803)—bash(8813)
Started: 729012 seconds ago
When: 02/02/2007 12:03:46 AM
Is Logged: Yes
Log Dir: /var/log/service/sshd
Log Status: Up
Log Pid: 3375
Log Started: 729013 seconds ago
Log When: 02/02/2007 12:03:45 AM

Dependencies: sshd
————————————————
Requires:
Needed By:
By using runit, the srv wrapper script makes it very easy to manage system daemons. Please note that every daemon shipped with Annvix uses srv.
Peers

srv also handles a concept called “peers”, which is an access control mechanism similar to using /etc/hosts.allow and /etc/hosts.deny. Services that use tcpsvd make use of peers to allow or deny access to those services. tcpsvd is another “super-server” similar to xinetd. It answers any connection requests, determines if the connecting system is permitted to use the service, and if so, hands it off to the appropriate program.
For example the sshd service uses tcpsvd in exactly this way. It’s run script looks like as following:
#!/bin/execlineb

/bin/fdmove -c 2 1

/bin/export PATH “/sbin:/bin:/usr/sbin:/usr/bin”

/sbin/chpst -e /etc/sysconfig/env/tcpsvd/
/sbin/chpst -e ./env/

/bin/multisubstitute {
import -D “localhost” HOSTNAME
import -D 0 IP
import -D 22 PORT
import -D 20 MAX_CONN
import -D 5 MAX_PER_HOST
import -D 20 MAX_BACKLOG
import OPTIONS
}

/sbin/tcpsvd -v -l ${HOSTNAME} -x peers.cdb -c ${MAX_CONN} -C ${MAX_PER_HOST} -b ${MAX_BACKLOG} ${IP} ${PORT}
/usr/sbin/sshd -i ${OPTIONS}

Essentially what happens here is that a number of variables are imported first from the global /etc/sysconfig/env/tcpsvd environment directory, then the service’s own ./env environment directory. The important thing to note here is the -x peers.cdb argument to tcpsvd.
This argument instructs tcpsvd to use peers information for ACLs as found in the peers.cdb file for this service. This file is a CDB copy of the contents of the ./peers directory for this service. This file is constructed every time srv is used to manage peers information for the service, by first writing the peers information to ./peers and then creating the CDB file by using the ipsvd-cdb tool.

Structure of ./peers

The peers directory is a regular directory that contains IP addresses, partial IP addresses, or hostnames with certain permissions that tell tcpsvd whether or not that IP (or hostname) is allowed to connect to the service. The catch-all file is ./peers/0, and it’s default permissions determine the default access type. This directory is essentially an ipsvd instructions directory; as such you can get more details from the ipsvd-instruct(5) manpage.

The file’s permissions determines the access to the service for that IP or hostname:
If neither the user’s read permission, nor the user’s execute permission is set for the file, the connection is closed immediately
If the file has the user’s execute permission set, ipsvd reads the contents of the file and runs /bin/sh -c ” instead of the default program given att he command line for this connection (i.e. the service itself)
If the file has the user’s read permission set, ipsvd reads the contents of the file and interprets each line as an instruction for this connection; thus allowing the connection
Essentially, to deny access to a connection, chmod 0 the file. To allow access to a connection, chmod 0644 the file. If you want to get fancy, you can have the file contain an alternate program to execute as it’s contents and chmod 0755 the file.

For instance, to disallow all connections to the sshd service, but allow connections from the 10.0.5.0 network and a single remote IP address (say 12.34.56.78), the ./peers directory would look thus:
# ls -l
total 4
———- 1 root admin 0 Dec 29 16:09 0
-rw-r–r– 1 root root 0 Feb 4 17:43 10.0.5
-rw-r–r– 1 root root 2 Nov 18 07:28 12.34.56.78

How srv handles peers

Manually manipulating ./peers is fine, but srv makes it simple to do basic ACLs. It doesn’t do things such as executing alternate programs based on the connection, but it will manipulate the peers information to the point that you can allow and deny access based on IP or hostname or network, and you can also set per-peer environment pair values, as well as the number of concurrent connections to the service.
The related srv commands are:
–peers | -p [service] - set peer information for the service (see below), or rebuild the peer instructions for the service if no peer control options are given
–env | -e [service] - set global environment pair values for the service
Along with the –peers command, a user can use the following peer control options:
–grant | -g - grant access to this service to the specified hosts, IPs, or networks
–exclude | -x - deny access to this service to the specified hosts, IPs, or networks
–remove | -y - remove peer information for the specified hosts, IPs, or networks
–env | -e - set per-peer environment pair values
–max | -m - set the number of concurrent connections for the specifies hosts, IPs, or networks to this service

An example will help towards gaining more understanding:
# srv –peers rsync -g 192.168.0.12 -e TRUSTED=yes -m 5
This command sets up peer information for the rsync service. It grants access to the IP 192.168.0.12, sets the environment variable $TRUSTED to “yes” (this is made available to the service), and sets the maximum concurrent connections to 5.

This command also explains that a user can have default “accept” to a service, a user can also override certain configuration options based on connecting IP or hostname. In this case, if access to the rsync service was globally permitted, the maximum number of concurrent connections per IP might be 2 for every IP other than that specified, which would permit 5. The environment variable $TRUSTED is set when this IP connects where it is not set for all others
By looking at this, it can be said that peers management is simple and powerful. This because a user can completely change how a service responds based on the connecting system.

Let’s have a look at another example:
# chmod 0 ./peers/0
# srv –env sshd MAX_PER_HOST=1
# srv –peers sshd -g secure.host.com -e OPTIONS=’-o “PermitRootLogin yes”‘-m 10
# srv –peers sshd -g host.com -m 3
A user will note that this series of commands will carry out following:
- disable all connections to sshd by default.
- set the maximum concurrency for all hosts to one connection per IP.
- grant access to sshd to secure.host.com with the environment variable $OPTIONS set to ‘-o “PermitRootLogin yes”‘ and a concurrency of 10 connections.
- raise the concurrency to three connections per IP to any *.host.com connections.

The third command is interesting. This is because the sshd service passes the value of $OPTIONS directly to sshd itself, a user can directly manipulate the server based on the incoming connection. A user can note that “PermitRootLogin” is set to “No” in sshd_config. All connections this will be the case, however, if a connection comes from secure.host.com, all of a sudden sshd will allow root logins because that option is passed to it.
The resulting ./peers/secure.host.com file would look like:
C10
+ OPTIONS=-o “PermitRootLogin yes”
The use of host names is fine, but it is recommended that a user should look up via DNS first. This means that if the IP 12.34.56.78 does not have a reverse DNS entry to secure.host.com, access will be granted based on the IP address and not the hostname.
Please note that in order to make use of this, a user will need to add -h to the tcpsvd command in the ./run script. By default, no services will attempt to do DNS lookups on incoming connections as it can get expensive in terms of connection speeds. If a user wants to enable this then he/she can change ./run so that instead of looking like:

/sbin/tcpsvd -v -l ${HOSTNAME} -x peers.cdb -c ${MAX_CONN} -C ${MAX_PER_HOST} -b ${MAX_BACKLOG} ${IP} ${PORT}
/usr/sbin/sshd -i ${OPTIONS}
it looks like:
/sbin/tcpsvd -v -h -l ${HOSTNAME} -x peers.cdb -c ${MAX_CONN} -C ${MAX_PER_HOST} -b ${MAX_BACKLOG} ${IP} ${PORT}
/usr/sbin/sshd -i ${OPTIONS}

If a user can change a run script, then he/she should keep in mind that upgrades to that package will never overwrite the changes. However, the new script will be named run.rpmnew and a user will examine the file for changes that may have been made and merge them in manually.

The way it works
At boot, Annvix uses runit rather than init to start the system. In runit’s stage 2 process, runsvdir is started to manage everything under /service. All that is in the /service directory are symlinks to directories in /var/service which is where rpm packages place directories and information in order to run supervised services. These directories are named after the service they start. Unlike initscripts that can (and often do) start more than one daemon, each service starts one and only one service. So, for instance, when running LDAP you would use service ldap start on most Linux distributions, but on Annvix you would use srv –up slapd; srv –up slurpd. In this case there are two daemons, thus two services: slapd and slurpd.

Inside each directory is a single file called run. run is the equivalent of an initscript’s start() function; all it does is start the service. The run script of spamd, for instance looks like this:
#!/bin/sh
PATH=”/sbin:/usr/sbin:/bin:/usr/bin”

# this runs spamd supervised

OPTIONS=”-c -m5 -H”

if [ -f ./env/OPTIONS ]; then
OPTIONS=`head -1 ./env/OPTIONS`
fi

exec /usr/bin/spamd $OPTIONS 2>&1
Like an initscript, it sources certain configuration files to get options for the daemon (in this case, the /var/service/spamd/env/OPTIONS file). You also see that the daemon is started with exec and that STDERR is redirected to STDOUT. This is not always desirable, however, and needs to be dealt with on a case-by-case basis. In the case of spamd, a sub-service is also started that writes all of spamd’s output to a logfile.

The logging service is another service that supervise handles, tied specifically to that particular service. This is done by using a log/ subdirectory of the service; so spamd’s logging service run script is /service/spamd/log/run. The contents of this file are:
#!/bin/execlineb

# logging for the spamd service

/bin/foreground { /usr/bin/install -m 0700 -d -o logger -g logger /var/log/service/spamd }
/bin/cd /var/log/service
/sbin/chpst -u logger /sbin/svlogd -tt /var/log/service/spamd

This script basically takes STDOUT from spamd and writes it, through the svlogd tool (which handles the naming and automatic rotation of log files) to the directory /var/log/service/spamd. In this directory you will find a few files, some with odd names that are rotated logfiles, and one of interest, particularly current. The current logfile is the latest output of the service.
If a user wants to debug a service or figure out why it isn’t starting. Often errors from a service will be written to STDERR, which, if you remember, we are redirecting to STDOUT, which is then being written to the logfiles that svlogd is handling.
If a user browses through the /var/log/service directory, then he/she will view a number of subdirectories. These subdirectories are log directories for other services, although not all services uses logging services (socklog is a notable exceptions). More often than not, the log files will be 0 bytes unless the program (like snort) is fairly verbose. As well, in many cases, services need to be started with debugging enabled in order to prevent them from forking into the background. In order for runsvdir to be able to control a service, it must not fork into the background.

If a user follows this tutorial guide then he/she would have learnt about managing supervised services.