(page 63) provide examples of each one. Subsequent steps describe your options
in answering these questions.
• Dealing with execute accesses is complex. You must decide how to proceed
with this entry regarding which execute permission type to grant to this entry:
Example 4.1
Learning Mode Exception: Controlling Access to Specific Resources
Reading log entries from /var/log/audit/audit.log.
Updating AppArmor profiles in /etc/apparmor.d.
Profile: /usr/sbin/xinetd
Program: xinetd
Execute: /usr/lib/cups/daemon/cups-lpd
Severity: unknown
[(I)nherit] / (P)rofile / (U)nconfined / (D)eny / Abo(r)t / (F)inish
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
less
as a pager or the
Mozilla* Web browser using Adobe Acrobat* to display PDF files.
Profile (px)
The child runs using its own profile, which must be loaded into the ker-
nel. 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 with 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 to the child process.
Unconfined (ux)
The child runs completely unconfined without any AppArmor profile
applied to the executed resource.
62
Novell AppArmor Administration Guide
