aa-autodep—Creating Approximate Profiles

This creates an approximate profile for the program or application selected. You can generate approximate profiles for binary executables and interpreted script programs. The resulting profile is called approximate because it does not necessarily contain all of the profile entries that the program needs to be properly confined by Novell AppArmor. The minimum aa-autodep approximate profile has at least a base include directive, which contains basic profile entries needed by most programs. For certain types of programs, aa-autodep generates a more expanded profile. The profile is generated by recursively calling ldd(1) on the executables listed on the command line.

To generate an approximate profile, use the aa-autodep program. The program argument can be either the simple name of the program, which aa-autodep finds by searching your shell's path variable, or it can be a fully qualified path. The program itself can be of any type (ELF binary, shell script, Perl script, etc.). aa-autodep generates an approximate profile to improve through the dynamic profiling that follows.

The resulting approximate profile is written to the /etc/apparmor.d directory using the Novell AppArmor profile naming convention of naming the profile after the absolute path of the program, replacing the forward slash (/) characters in the path with period (.) characters. The general form of aa-autodep is to enter the following in a terminal window when logged in as root:

aa-autodep [ -d /path/to/profiles ] [program1 program2...]

If you do not enter the program name or names, you are prompted for them. /path/to/profiles overrides the default location of /etc/apparmor.d, should you keep profiles in a location other than the default.

To begin profiling, you must create profiles for each main executable service that is part of your application (anything that might start without being a child of another program that already has a profile). Finding all such programs depends on the application in question. Here are several strategies for finding such programs:

Directories

If all of the programs you want to profile are in a directory and there are no other programs in that directory, the simple command aa-autodep /path/to/your/programs/* creates nominal profiles for all programs in that directory.

ps command

You can run your application and use the standard Linux ps command to find all processes running. Then manually hunt down the location of these programs and run the aa-autodep program for each one. If the programs are in your path, aa-autodep finds them for you. If they are not in your path, the standard Linux command find might be helpful in finding your programs. Execute find / -name '*foo*' -print to determine an application's path (*foo* being an example application).

aa-complain—Entering Complain or Learning Mode

The complain or learning mode tool (aa-complain) detects violations of Novell AppArmor profile rules, such as the profiled program accessing files not permitted by the profile. The violations are permitted, but also logged. To improve the profile, turn complain mode on, run the program through a suite of tests to generate log events that characterize the program's access needs, then postprocess the log with the Novell AppArmor tools to transform log events into improved profiles.

Manually activating complain mode (using the command line) adds a flag to the top of the profile so that /bin/foo becomes /bin/foo flags=(complain). To use complain mode, open a terminal window and enter one of the following lines as root:

Each of the above commands activates the complain mode for the profiles or programs listed. If the program name does not include its entire path, aa-complain searches $PATH for the program. So, for instance, aa-complain /usr/sbin/* finds profiles associated with all of the programs in /usr/sbin and put them into complain mode. aa-complain /etc/apparmor.d/* puts all of the profiles in /etc/apparmor.d into complain mode.

aa-enforce—Entering Enforce Mode

The enforce mode detects violations of Novell AppArmor profile rules, such as the profiled program accessing files not permitted by the profile. The violations are logged and not permitted. The default is for enforce mode to be enabled. To log the violations only, but still permit them, use complain mode. Enforce toggles with complain mode.

Manually activating enforce mode (using the command line) adds a flag to the top of the profile so that /bin/foo becomes /bin/foo flags=(enforce). To use enforce mode, open a terminal window and enter one of the following lines as root.

Each of the above commands activates the enforce mode for the profiles and programs listed.

If you do not enter the program or profile names, you are prompted to enter one. /path/to/profiles overrides the default location of /etc/apparmor.d.

The argument can be either a list of programs or a list of profiles. If the program name does not include its entire path, aa-enforce searches $PATH for the program.

aa-genprof—Generating Profiles

aa-genprof is Novell AppArmor's profile generating utility. It runs aa-autodep on the specified program, creating an approximate profile (if a profile does not already exist for it), sets it to complain mode, reloads it into Novell AppArmor, marks the log, and prompts the user to execute the program and exercise its functionality. Its syntax is as follows:

aa-genprof [ -d /path/to/profiles ]  program

If you were to create a profile for the the Apache Web server program httpd2-prefork, you would do the following as root:

aa-logprof—Scanning the System Log

aa-logprof is an interactive tool used to review the learning or complain mode output found in the log entries under /var/log/audit/audit.log or /var/log/messages (if auditd is not running) and generate new entries in Novell AppArmor security profiles.

When you run aa-logprof, it begins to scan the log files produced in learning or complain mode and, if there are new security events that are not covered by the existing profile set, it gives suggestions for modifying the profile. The learning or complain mode traces program behavior and enters it in the log. aa-logprof uses this information to observe program behavior.

If a confined program forks and executes another program, aa-logprof sees this and asks the user which execution mode should be used when launching the child process. The execution modes ix, px, Px, ux, and Ux are options for starting the child process. If a separate profile exists for the child process, the default selection is px. If one does not exist, the profile defaults to ix. Child processes with separate profiles have aa-autodep run on them and are loaded into AppArmor, if it is running.

When aa-logprof exits, profiles are updated with the changes. If the AppArmor module is running, the updated profiles are reloaded and, if any processes that generated security events are still running in the null-complain-profile, those processes are set to run under their proper profiles.

To run aa-logprof, enter aa-logprof into a terminal window while logged in as root. The following options can be used for aa-logprof:

aa-logprof -d /path/to/profile/directory/

Specifies the full path to the location of the profiles if the profiles are not located in the standard directory, /etc/apparmor.d/.

aa-logprof -f /path/to/logfile/

Specifies the full path to the location of the log file if the log file is not located in the default directory, /var/log/audit/audit.log or /var/log/messages (if auditd is not running).

aa-logprof -m "string marker in logfile"

Marks the starting point for aa-logprof to look in the system log. aa-logprof ignores all events in the system log before the specified mark. If the mark contains spaces, it must be surrounded by quotes to work correctly. For example:

aa-logprof -m"17:04:21"

or

logprof -m e2ff78636296f16d0b5301209a04430d

aa-logprof scans the log, asking you how to handle each logged event. Each question presents a numbered list of Novell AppArmor rules that can be added by pressing the number of the item on the list.

By default, aa-logprof looks for profiles in /etc/apparmor.d/ and scans the log in /var/log/messages. In many cases, running aa-logprof as root is enough to create the profile.

However, there might be times when you need to search archived log files, such as if the program exercise period exceeds the log rotation window (when the log file is archived and a new log file is started). If this is the case, you can enter zcat -f `ls -1tr /var/log/messages*` | aa-logprof -f -.

aa-logprof Example 1

The following is an example of how aa-logprof addresses httpd2-prefork accessing the file /etc/group. [] indicates the default option.

In this example, the access to /etc/group is part of httpd2-prefork accessing name services. The appropriate response is 1, which includes a predefined set of Novell AppArmor rules. Selecting 1 to #include the name service package resolves all of the future questions pertaining to DNS lookups and also makes the profile less brittle in that any changes to DNS configuration and the associated name service profile package can be made just once, rather than needing to revise many profiles.

Profile:  /usr/sbin/httpd2-prefork
Path:     /etc/group
New Mode: r

[1 - #include <abstractions/nameservice>]
 2 - /etc/group
[(A)llow] / (D)eny / (N)ew / (G)lob / Glob w/(E)xt / Abo(r)t / (F)inish

Select one of the following responses:

Select

Allows access to the selected directory path.

Allow

Allows access to the specified directory path entries. Novell AppArmor suggests file permission access. For more information about this, refer to Section 4.8, File Permission Access Modes.

Deny

Prevents the program from accessing the specified directory path entries. Novell AppArmor then moves on to the next event.

New

Prompts you to enter your own rule for this event, allowing you to specify whatever form of regular expression you want. If the expression you enter does not actually satisfy the event that prompted the question in the first place, Novell AppArmor asks you for confirmation and lets you reenter the expression.

Glob

Select either a specific path or create a general rule using wild cards that matches on a broader set of pathnames. To select any of the offered paths, enter the number that is printed in front of the paths then decide how to proceed with the selected item.

For more information about globbing syntax, refer to Section 4.7, Pathnames and Globbing.

Glob w/Ext

This modifies the original directory path while retaining the filename extension. For example, /etc/apache2/file.ext becomes /etc/apache2/*.ext, adding the wild card (asterisk) in place of the filename. This allows the program to access all files in the suggested directory that end with the .ext extension.

Abort

Aborts aa-logprof, losing all rule changes entered so far and leaving all profiles unmodified.

Finish

Closes aa-logprof, saving all rule changes entered so far and modifying all profiles.

aa-logprof Example 2

In an example from profiling vsftpd, see this question:

Profile:  /usr/sbin/vsftpd
Path:     /y2k.jpg
New Mode: r

[1 - /y2k.jpg]

(A)llow / [(D)eny] / (N)ew / (G)lob / Glob w/(E)xt / Abo(r)t / (F)inish

Several items of interest appear in this question. First, note that vsftpd is asking for a path entry at the top of the tree, even though vsftpd on openSUSE serves FTP files from /srv/ftp by default. This is because httpd2-prefork uses chroot and, for the portion of the code inside the chroot jail, Novell AppArmor sees file accesses in terms of the chroot environment rather than the global absolute path.

The second item of interest is that you might want to grant FTP read access to all JPEG files in the directory, so you could use Glob w/Ext and use the suggested path of /*.jpg. Doing so collapses all previous rules granting access to individual .jpg files and forestalls any future questions pertaining to access to .jpg files.

Finally, you might want to grant more general access to FTP files. If you select Glob in the last entry, aa-logprof replaces the suggested path of /y2k.jpg with /*. Alternatively, you might want to grant even more access to the entire directory tree, in which case you could use the New path option and enter /**.jpg (which would grant access to all .jpg files in the entire directory tree) or /** (which would grant access to all files in the directory tree).

The above deal with read accesses. Write accesses are similar, except that it is good policy to be more conservative in your use of regular expressions for write accesses.

Dealing with execute accesses is more complex. You must decide which execute permissions to grant:

inherit (ix)

The child inherits the parent's profile, running with the same access controls as the parent. This 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. This mode is often used when the child program is a helper application, such as the /usr/bin/mail client using the less program as a pager or the Mozilla Web browser using the Acrobat program to display PDF files.

profile (px)

The child runs using its own profile, which must be loaded into the kernel. If the profile is not present, attempts to execute the child fail with permission denied. This is most useful if the parent program is invoking a global service, such as DNS lookups or sending mail via your system's MTA.

Choose the profile with clean exec (Px) option to scrub the environment of environment variables that could modify execution behavior when passed on to the child process.

unconfined (ux)

The child runs completely unconfined without any Novell AppArmor profile applied to the executed resource.

Choose the unconfined with clean exec (Ux) option to scrub the environment of environment variables that could modify execution behavior when passed on to the child process. This option introduces a security vulnerability that could be used to exploit AppArmor. Only use it as a last resort.

mmap (m)

This permission denotes that the program running under the profile can access the resource using the mmap system call with the flag PROT_EXEC. This means that the data mapped in it can be executed. You are prompted to include this permission if it is requested during a profiling run.

In the following example, the /usr/bin/mail mail client is being profiled and aa-logprof has discovered that /usr/bin/mail executes /usr/bin/less as a helper application to page long mail messages. Consequently, it presents this prompt:

/usr/bin/nail -> /usr/bin/less
(I)nherit / (P)rofile / (U)nconfined / (D)eny

The program /usr/bin/less appears to be a simple one for scrolling through text that is more than one screen long and that is in fact what /usr/bin/mail is using it for. However, less is actually a large and powerful program that makes use of many other helper applications, such as tar and rpm.

You do not want to automatically run rpm when reading mail messages (that leads directly to a Microsoft* Outlook–style virus attack, because rpm has the power to install and modify system programs) and so, in this case, the best choice is to use Inherit. This results in the less program executed from this context running under the profile for /usr/bin/mail. This has two consequences:

In other circumstances, you might instead want to use the Profile option. This has two effects on aa-logprof:

Finally, you might want to grant the child process very powerful access by specifying Unconfined. This writes Ux into the parent profile so that when the child runs, it runs without any Novell AppArmor profile being applied at all, but the environment is cleaned of some environment variables, which can alter execution behavior, before the child inherits it. Running unconfined means running with no protection and should only be used when absolutely required.

aa-unconfined—Identifying Unprotected Processes

The aa-unconfined command examines open network ports on your system, compares that to the set of profiles loaded on your system, and reports network services that do not have Novell AppArmor profiles. It requires root privilege and that it not be confined by a Novell AppArmor profile.

aa-unconfined must be run as root to retrieve the process executable link from the /proc file system. This program is susceptible to the following race conditions: