3.5. Two Methods of Profiling

3.5. Two Methods of Profiling
	Chapter 3. Building Novell AppArmor Profiles

Given the syntax for Novell AppArmor profiles in Section 3.1, “Profile Components and Syntax” (↑Novell AppArmor 2.0 Administration Guide), you could create profiles without using the tools. However, the effort involved would be substantial. To avoid such a hassle, use the Novell AppArmor tools to automate the creation and refinement of profiles.

There are two ways to approach creating Novell AppArmor profiles, along with tools to support both methods.

Stand-Alone Profiling: A method suitable for profiling small applications that have a finite run time, such as user client applications like mail clients. For more information, refer to Section 3.5.1, “Stand-Alone Profiling” (↑Novell AppArmor 2.0 Administration Guide).
Systemic Profiling: A method suitable for profiling large numbers of programs all at once and for profiling applications that may run for days, weeks, or continuously across reboots, such as network server applications like Web servers and mail servers. For more information, refer to Section 3.5.2, “Systemic Profiling” (↑Novell AppArmor 2.0 Administration Guide).

Automated profile development becomes more manageable with the Novell AppArmor tools:

Decide which profiling method suits your needs.
Perform a static analysis. Run either genprof or autodep, depending on the profiling method you have chosen.
Enable dynamic learning. Activate learning mode for all profiled programs.

3.5.1. Stand-Alone Profiling

Stand-alone profile generation and improvement is managed by a program called genprof. This method is easy because genprof takes care of everything, but is limited because it requires genprof to run for the entire duration of the test run of your program (you cannot reboot the machine while you are still developing your profile).

To use genprof for the stand-alone method of profiling, refer to Section 3.5.3.4, “genprof” (↑Novell AppArmor 2.0 Administration Guide).

3.5.2. Systemic Profiling

This method is called systemic profiling because it updates all of the profiles on the system at once, rather than focusing on the one or few being targeted by genprof or standalone profiling.

With systemic profiling, building and improving profiles are somewhat less automated, but more flexible. This method is suitable for profiling long-running applications whose behavior continues after rebooting or a large numbers of programs to profile all at once.

Build a Novell AppArmor profile for a group of applications as follows:

Create profiles for the individual programs that make up your application. Even though this approach is systemic, Novell AppArmor still only monitors those programs with profiles and their children. Thus, to get Novell AppArmor to consider a program, you must at least have autodep create an approximate profile for it. To create this approximate profile, refer to Section 3.5.3.1, “autodep” (↑Novell AppArmor 2.0 Administration Guide).
Put relevant profiles into learning or complain mode. Activate learning or complain mode for all profiled programs by entering complain /etc/apparmor.d/* in a terminal window while logged in as root.
When in learning mode, access requests are not blocked even if the profile dictates that they should be. This enables you to run through several tests (as shown in Step 3 (↑Novell AppArmor 2.0 Administration Guide)) and learn the access needs of the program so it runs properly. With this information, you can decide how secure to make the profile.
Refer to Section 3.5.3.2, “Complain or Learning Mode” (↑Novell AppArmor 2.0 Administration Guide) for more detailed instructions for using learning or complain mode.
Exercise your application. Run your application and exercise its functionality. How much to exercise the program is up to you, but you need the program to access each file representing its access needs. Because the execution is not being supervised by genprof, this step can go on for days or weeks and can span complete system reboots.
Analyze the log. In systemic profiling, run logprof directly instead of letting genprof run it (as in stand-alone profiling). The general form of logprof is:
```
logprof [ -d /path/to/profiles ] [ -f /path/to/logfile ]
```
Refer to Section 3.5.3.5, “logprof” (↑Novell AppArmor 2.0 Administration Guide) for more information about using logprof.
Repeat Steps 3-4. This generates optimum profiles. An iterative approach captures smaller data sets that can be trained and reloaded into the policy engine. Subsequent iterations generate fewer messages and run faster.
Edit the profiles. You might want to review the profiles that have been generated. You can open and edit the profiles in /etc/apparmor.d/ using vim. For help using vim to its fullest capacity, refer to Section 3.5.3.8, “apparmor.vim” (↑Novell AppArmor 2.0 Administration Guide).
Return to “enforce” mode. This is when the system goes back to enforcing the rules of the profiles, not just logging information. This can be done manually by removing the flags=(complain) text from the profiles or automatically by using the enforce command, which works identically to the complain command, but sets the profiles to enforce mode.
To ensure that all profiles are taken out of complain mode and put into enforce mode, enter enforce /etc/apparmor.d/*.
Rescan all profiles. To have Novell AppArmor rescan all of the profiles and change the enforcement mode in the kernel, enter /etc/init.d/apparmor restart.

3.5.3. Summary of Profiling Tools

All of the Novell AppArmor profiling utilities are provided by the apparmor-utils RPM package and most are stored in /usr/sbin. The following sections introduce each tool.

3.5.3.1. autodep

This creates an approximate profile for the program or application you are autodepping. 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 autodep approximate profile has at least a base include directive, which contains basic profile entries needed by most programs. For certain types of programs, 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 autodep program. The program argument can be either the simple name of the program, which 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.) and autodep generates an approximate profile, to be improved 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 autodep is to enter the following in a terminal window when logged in as root:

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.

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 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. You then need to manually hunt down the location of these programs and run the autodep program for each one. If the programs are in your path, autodep finds them for you. If they are not in your path, the standard Linux command locate might be helpful in finding your programs. If locate does not work (it is not installed by default on SUSE Linux), use find . -name '*foo*' -print.

3.5.3.2. Complain or Learning Mode

The complain or learning mode tool 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 the 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 a root user.

If the example program (program1) is in your path, use:
```
complain [program1 program2 ...]
```
If the program is not in your path, specify the entire path as follows:
```
complain /sbin/program1
```
If the profiles are not in /etc/apparmor.d, type the following to override the default location:
```
complain /path/to/profiles/ program1
     
```
Specify the profile for program1, as follows:
```
complain /etc/apparmor.d/sbin.program1
```

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

3.5.3.3. Enforce Mode

The enforce mode tool 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 turned on. Turn complain mode on when you want the Novell AppArmor profiles to control the access of the program that is profiled. 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 a root user.

If the example program (program1) is in your path, use:
```
enforce [program1 program2 ...]
```
If the program is not in your path, specify the entire path, as follows:
```
enforce /sbin/program1
```
If the profiles are not in /etc/apparmor.d, use the following to override the default location:
```
enforce /path/to/profiles/ program1
```
Specify the profile for program1, as follows:
```
enforce /etc/apparmor.d/sbin.program1
```

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, enforce searches $PATH for the program. For instance, enforce /usr/sbin/* finds profiles associated with all of the programs in /usr/sbin and puts them into enforce mode. enforce /etc/apparmor.d/* puts all of the profiles in /etc/apparmor.d into enforce mode.

3.5.3.4. genprof

genprof (or Generate Profile) is Novell AppArmor's profile generating utility. It runs 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 syslog, and prompts the user to execute the program and exercise its functionality. Its syntax is as follows:

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 in a root shell:

Enter rcapache2 stop.

Next, enter genprof httpd2-prefork.

Now genprof does the following:

Resolves the full path of httpd2-prefork based on your shell's path variables. You can also specify a full path. On SUSE Linux, the full path is /usr/sbin/httpd2-prefork.

Checks to see if there is an existing profile for httpd2-prefork. If there is one, it updates it. If not, it creates one using the autodep program described in Section 3.5.3, “Summary of Profiling Tools” (↑Novell AppArmor 2.0 Administration Guide).

	Note
There is a naming convention relating the full path of a program to its profile filename so that the various Novell AppArmor profiling tools can consistently manipulate them. The convention is to replace a forward slash (`/`) with period (`.`) so that the profile for `/usr/sbin/httpd2-prefork` is stored in `/etc/apparmor.d/usr.sbin.httpd2-prefork`.

Puts the profile for this program into learning or complain mode so that profile violations are logged but are permitted to proceed. A log event looks like this:
```
Oct  9 15:40:31 AppArmor: PERMITTING r access to /etc/apache2/httpd.conf (httpd2-prefork(6068) profile /usr/sbin/httpd2-prefork active /usr/sbin/httpd2-prefork)
```
Marks syslog with a beginning marker of log events to consider. Example:
```
Sep 13 17:48:52 h2o root: GenProf: e2ff78636296f16d0b5301209a04430d
```

When prompted by the tool, run the application to profile in another terminal window and perform as many of the application functions as possible so learning mode can log the files and directories to which the program requires access in order to function properly. For example, in a new terminal window, enter rcapache2 start.
Select from the following options, which can be used after you have executed the program functionality:
- S runs logprof against the system log from where it was marked when genprof was started and reloads the profile.
  If system events exist in the log, Novell AppArmor parses the learning mode log files. This generates a series of questions that you must answer to guide genprof in generating the security profile.
- F exits the tool and returns to the main menu.
Note
If requests to add hats appear, proceed to Chapter 5, Profiling Your Web Applications Using ChangeHat Apache (↑Novell AppArmor 2.0 Administration Guide).
Answer two types of questions:
- A resource is requested by a profiled program that is not in the profile (see Example 3.1, “Learning Mode Exception: Controlling Access to Specific Resources” (↑Novell AppArmor 2.0 Administration Guide)).
- A program is executed by the profiled program and the security domain transition has not been defined (see Example 3.2, “Learning Mode Exception: Defining Execute Permissions for an Entry” (↑Novell AppArmor 2.0 Administration Guide)).
Each of these categories results in a series of questions that you must answer to add the resource to the profile or to add the program into the profile. The following two figures show an example of each one. Subsequent steps describe your options in answering these questions.
Example 3.1. Learning Mode Exception: Controlling Access to Specific Resources
```
Reading log entries from /var/log/messages.
Updating apparmor profiles in /etc/apparmor.d.

Profile: /usr/sbin/xinetd
Execute: /usr/sbin/vsftpd

[(I)nherit] / (P)rofile / (U)nconfined / (D)eny / Abo(r)t / (F)inish)
```
Dealing with execute accesses is complex. You must decide which of the three kinds of execute permissions to grant the program:
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 fails 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.
unconfined (ux)
The child runs completely unconfined without any Novell AppArmor profile being applied to the executed resource.
Example 3.2. Learning Mode Exception: Defining Execute Permissions for an Entry
```
Adding /bin/ps ix to profile.

Profile:  /usr/sbin/xinetd
Path:     /etc/hosts.allow
New Mode: r

 [1 - /etc/hosts.allow]

[(A)llow] / (D)eny / (N)ew / (G)lob / Glob w/(E)xt / Abo(r)t / (F)inish
```
The above menu shows Novell AppArmor suggesting directory path entries that have been accessed by the application you are profiling. It might also require you to define execute permissions for entries.
Novell AppArmor provides one or more pathnames or includes. By clicking the option number, select from one or more of the following options, then proceed to the next step.
Note
All of these options are not always presented in the Novell AppArmor menu.
#include
This is the section of a Novell AppArmor profile that refers to an include file, which procures access permissions for programs. By using an include, you can give the program access to directory paths or files that are also required by other programs. Using includes can reduce the size of a profile. It is good practice to select includes when suggested.
Globbed Version
This is accessed by clicking Glob as described in the next step. For information about globbing syntax, refer to Section 3.6, “Pathnames and Globbing” (↑Novell AppArmor 2.0 Administration Guide).
Actual Path Name
This is the literal path to which the program needs access so that it can run properly.
After you select the pathname or include, you can process it as an entry into the Novell AppArmor profile by clicking Allow or Deny. If you are not satisfied with the directory path entry as it is displayed, you can also Glob or Edit it.
The following options are available to process the learning mode entries and to build the profile:
Press Enter
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, refer to Section 3.7, “File Permission Access Modes” (↑Novell AppArmor 2.0 Administration Guide)
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
Clicking this modifies the directory path (by using wild cards) to include all files in the suggested entry directory. Double-clicking it grants access to all files and subdirectories beneath the one shown.
For more information on globbing syntax, refer to Section 3.6, “Pathnames and Globbing” (↑Novell AppArmor 2.0 Administration Guide).
Glob w/Ext
Clicking 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. Double-clicking it grants access to all files (with the particular extension) and subdirectories beneath the one shown.
Edit
Lets you edit the selected line. The new edited line appears at the bottom of the list.
Abort
Aborts logprof, dumping all rule changes entered so far and leaving all profiles unmodified.
Finish
Closes logprof, saving all rule changes entered so far and modifying all profiles.
To view and edit your profile using vim, enter vim /etc/apparmor.d/profilename in a terminal window. To enable syntax coloring when you edit a Novell AppArmor profile in vim, use the commands :syntax on then :set syntax=apparmor. For more information about about vim and syntax coloring, refer to Section 3.5.3.8, “apparmor.vim” (↑Novell AppArmor 2.0 Administration Guide).

3.5.3.5. logprof

logprof is an interactive tool used to review the learning or complain mode output found in the syslog entries then generate new entries in Novell AppArmor security profiles.

When you run 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 syslog. logprof uses this information to observe program behavior.

If a confined program forks and execs another program, logprof sees this and asks the user which execution mode should be used when launching the child process. The following execution modes are options for starting the child process: ix, px, and ux. 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 autodep run on them and are loaded into Novell AppArmor, if it is running.

When 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 logprof, enter logprof into a terminal window while logged in as root. The following options can also be used for logprof:

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/.
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/messages.
logprof -m "string marker in logfile": Marks the starting point for logprof to look in the system log. logprof ignores all events in the system log before the specified mark is seen. If the mark contains spaces, it must be surrounded with quotes to work correctly. Example: logprof -m e2ff78636296f16d0b5301209a04430d

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, logprof looks for profiles in /etc/apparmor.d/ and scans the log in /var/log/messages so, in many cases, running logprof as root is enough to create the profile.

However, there might 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*` | logprof -f -.

3.5.3.6. logprof Example 1

Following is an example of how logprof addresses httpd2-prefork accessing the file /etc/group. The example uses [] to indicate 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 pulls in 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 nameservice 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:

Press Enter

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 3.7, “File Permission Access Modes” (↑Novell AppArmor 2.0 Administration Guide).

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

Clicking this modifies the directory path (by using wild cards) to include all files in the suggested entry directory. Double-clicking it grants access to all files and subdirectories beneath the one shown.

For more information about globbing syntax, refer to Section 3.6, “Pathnames and Globbing” (↑Novell AppArmor 2.0 Administration Guide).

Glob w/Ext

Clicking 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. Double-clicking it grants access to all files (with the particular extension) and subdirectories beneath the one shown.

Edit

Lets you edit the selected line. The new edited line appears at the bottom of the list.

Abort

Aborts logprof, dumping all rule changes entered so far and leaving all profiles unmodified.

Finish

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

3.5.3.7. logprof Example 2

In an example from profiling vsftpd, we 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 SUSE Linux 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 of the 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, logprof replaces the suggested path of /y2k.jpg with /*. Or 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 of the three kinds of 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 fails 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.
unconfined (ux): The child runs completely unconfined without any Novell AppArmor profile applied to the executed resource.

In the following example, the /usr/bin/mail mail client is being profiled and 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)nconstrained / (D)eny

	Tip
The actual executable file for `/usr/bin/mail` turns out to be `/usr/bin/nail`, which is not a typographical error.

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.

	Tip
Run less on a tar ball or an RPM file and it shows you the inventory of these containers.

You do not want to automatically run rpm when reading mail messages (that leads directly to a Microsoft* Outlook–style virus attacks, 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:

You need to add all of the basic file accesses for /usr/bin/less to the profile for /usr/bin/mail.
You can avoid adding the helper applications, such as tar and rpm, to the /usr/bin/mail profile so that when /usr/bin/mail runs /usr/bin/mail/less in this context, the less program is far less dangerous than it would be without Novell AppArmor protection.

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

The rule written into the profile is px, which forces the transition to the child's own profile.
logprof constructs a profile for the child and starts building it, in the same way that it built the parent profile, by ascribing events for the child process to the child's profile and asking the logprof user questions as above.

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. This means running with no protection and should only be used when absolutely required.

3.5.3.8. apparmor.vim

A syntax coloring file for the vim text editor highlights various features of an Novell AppArmor profile with colors. Using vim and the Novell AppArmor syntax mode for vim, you can see the semantic implications of your profiles with color highlighting. Use vim to view and edit your profile by typing vim at a terminal window.

To enable the syntax coloring when you edit a Novell AppArmor profile in vim, use the commands :syntax on then :set syntax=apparmor. Alternatively, you can place these lines in your ~/.vimrc file:

syntax on
set modeline
set modelines=5

When you enable this feature, vim colors the lines of the profile for you:

Blue: #include lines that pull in other Novell AppArmor rules and comments that begin with #
White: Ordinary read access lines
Brown: Capability statements and complain flags
Yellow: Lines that grant write access
Green: Lines that grant execute permission (either ix or px)
Red: Lines that grant unconfined access (ux)
Red background: Syntax errors that are not loading properly into the AppArmor modules

	Note
There is a security risk when using these lines in your `.vimrc` file, because it causes vim to trust the syntax mode presented in files you are editing. It might enable an attacker to send you a file to open with vim that might do something unsafe.

Use the apparmor.vim and vim man pages and the :help syntax from within the vim editor for further vim help about syntax highlighting. The Novell AppArmor syntax is stored in /usr/share/vim/current/syntax/apparmor.vim.

3.5.3.9. Unconfined

The 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.

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:

An unlinked executable is mishandled
An executable started before a Novell AppArmor profile is loaded does not appear in the output, despite running without confinement
A process that dies between netstat(8) and further checks is mishandled

	Note
This program lists processes using TCP and UDP only. In short, this program is unsuitable for forensics use and is provided only as an aid to profiling all network-accessible processes in the lab.

For more information about the science and security of Novell AppArmor, refer to the following papers:

SubDomain: Parsimonious Server Security by Crispin Cowan, Steve Beattie, Greg Kroah-Hartman, Calton Pu, Perry Wagle, and Virgil Gligor

Describes the initial design and implementation of Novell AppArmor. Published in the proceedings of the USENIX LISA Conference, December 2000, New Orleans, LA.

This paper is now out of date, describing syntax and features that are different from the current Novell AppArmor product. This paper should be used only for scientific background and not for technical documentation.

Defcon Capture the Flag: Defending Vulnerable Code from Intense Attack by Crispin Cowan, Seth Arnold, Steve Beattie, Chris Wright, and John Viega

A good guide to strategic and tactical use of Novell AppArmor to solve severe security problems in a very short period of time. Published in the Proceedings of the DARPA Information Survivability Conference and Expo (DISCEX III), April 2003, Washington, DC.

	Note
If requests to add hats appear, proceed to Chapter 5, Profiling Your Web Applications Using ChangeHat Apache (↑Novell AppArmor 2.0 Administration Guide).

	Note
All of these options are not always presented in the Novell AppArmor menu.


3.4. Building Novell AppArmor Profiles Using the Command Line Interface		3.6. Pathnames and Globbing