This document helps you understand the main concepts behind Novell® AppArmor—the content of AppArmor profiles. Learn how to create or modify AppArmor profiles. You can create and manage AppArmor profile in three different ways. The most convenient interface to AppArmor is provided by means of the AppArmor YaST modules which can be used either in graphical or ncurses mode. The same functionality is provided by the AppArmor command line tools or if you just edit the profiles in a text editor.
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).
Use the rcapparmor command with one of the following parameters:
Use the rcaaeventd command to control event logging with aa-eventd. Use the start and stop options to toggle the status of the aa-eventd and check its status using the status.
approximatebecause it does not necessarily contain all of the profile entries that the program needs to be confined properly.
forever.
To apply systemic profiling, proceed as follows:
When using genprof, logprof, or YaST in learning mode, you get several options for how to proceed:
# a variable definition
@{HOME} = /home/*/ /root/
# a comment about foo.
/usr/bin/foo {
/bin/mount ux,
/dev/{,u}random r,
/etc/ld.so.cache r,
/etc/foo.conf r,
/etc/foo/* r,
/lib/ld-*.so* mr,
/lib/lib*.so* mr,
/proc/[0-9]** r,
/usr/lib/** mr,
/tmp/foo.pid wr,
/tmp/foo.* lrw,
/@{HOME}/.foo_file rw,
# a comment about foo's subprofile, bar.
^bar {
/lib/ld-*.so* mr,
/usr/bin/bar px,
/var/spool/* rwl,
}
}
Profiles are simple text files in the /etc/apparmor.d directory.
They consist of several parts: #include, capability entries,
rules, and hats.
This is the section of an AppArmor profile that refers to an include file, which mediates 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.
To assist you in profiling your applications, AppArmor provides three classes of #includes: abstractions, program chunks, and variables.
Abstractions are #includes that are grouped by common application tasks. These tasks include access to authentication mechanisms, access to name service routines, common graphics requirements, and system accounting, for example, base, consoles, kerberosclient, perl, user-mail, user-tmp, authentication, bash, nameservice.
Program chunks are access controls for specific programs that a system administrator might want to control based on local site policy. Each chunk is used by a single program.
Using variables, you can design your profiles to be portable to different environments. Changes in the variable's content are just made in the variable definition while the profile containing the variable can remain untouched.
Capabilities statements are simply the word capability
followed
by the name of the POSIX.1e capability as defined in the capabilities(7) man
page.
For executables that may be called from the confined programs, the profile creating tools ask you for an appropriate mode, which is also reflected directly in the profile itself:
WARNING: Running in ux Mode
Avoid running programs in ux mode as much as possible. A program running in ux mode is not only totally unprotected by AppArmor, but child processes inherit certain environment variables from the parent that might influence the child's execution behavior and create possible security risks.
For more information about the different file execute modes, refer to the apparmor.d(5) man page. For more information about setgid and setuid environment scrubbing, refer to the ld.so(8) man page.
An AppArmor profile represents a security policy for an individual
program instance or process. It applies to an executable program,
but if a portion of the program needs different access permissions than
other portions, the program can change hats
to use
a different security context, distinctive from the access of the
main program. This is known as a hat or subprofile.
A profile can have an arbitrary number of subprofiles, but there are only two levels: a subprofile cannot have further sub-subprofiles.
The AppArmor ChangeHat feature can be used by applications to access hats or subprofiles during execution. Currently the packages apache2-mod_apparmor and tomcat_apparmor utilize ChangeHat to provide sub-process confinement for the Apache Web server and the Tomcat servlet container.
The tool sitar
gathers all system configuration
information available from your system and creates comprehensive
system documentation. It can be used to document all new and changed
profiles.
All AppArmor events are logged using the system's audit interface (the auditd logging to /var/log/audit/audit.log). On top of this infrastructure, event notification can be configured. Configure this feature using YaST. It is based on severity levels according to /etc/apparmor/severity.db. Notification frequency and type of notification (such as e-mail) can be configured.
If auditd is not running, AppArmor logs to the system log located under /var/log/messages using the LOG_KERN facility.
Use YaST for generating reports in CSV or HTML format.
To learn more about the AppArmor project, check out the project's home page under http://en.opensuse.org/AppArmor. Find more information on the concept and the configuration of AppArmor in the Novell AppArmor Administration Guide.