diff --git a/docs/apparmor.pod b/docs/apparmor.pod index 9b985fff9..f52d1325e 100644 --- a/docs/apparmor.pod +++ b/docs/apparmor.pod @@ -39,7 +39,6 @@ SysV initscript, which is used like this: # /etc/init.d/boot.apparmor start # /etc/init.d/boot.apparmor stop # /etc/init.d/boot.apparmor restart - # /etc/init.d/boot.apparmor kill AppArmor can operate in two modes: I, and I: @@ -56,7 +55,7 @@ policy violation attempts to syslogd. I - Profiles loaded in C mode will not enforce policy. Instead, it will report policy violation attempts. This mode is convenient for developing profiles. To manage complain mode for individual profiles the -utilities /usr/bin/complain and /usr/bin/enforce can be used. +utilities aa-complain(8) and aa-enforce(8) can be used. These utilities take a program name as an argument. @@ -65,7 +64,7 @@ These utilities take a program name as an argument. Profiles are traditionally stored in files in F under filenames with the convention of replacing the B in pathnames with B<.> (except for the root B) so profiles are easier to manage -(e.g. the F profile would be named F). +(e.g. the F profile would be named F). Profiles are applied to a process at exec(3) time (as seen through the execve(2) system call); an already running process cannot be confined. @@ -98,15 +97,17 @@ A confined process can not call mknod(2) to create character or block devices. =head1 ERRORS When a confined process tries to access a file it does not have permission -to access, the kernel will report a message to klogd, similar to: +to access, the kernel will report a message through audit, similar to: + + audit(1148420912.879:96): REJECTING x access to /bin/uname + (sh(6646) profile /tmp/sh active /tmp/sh) + + audit(1148420912.879:97): REJECTING r access to /bin/uname + (sh(6646) profile /tmp/sh active /tmp/sh) + + audit(1148420944.837:98): REJECTING access to capability + 'dac_override' (sh(6641) profile /tmp/sh active /tmp/sh) - AppArmor: REJECTING x access to /bin/bash (irssi(2667) - profile /usr/local/bin/irssi active /usr/local/bin/irssi) - AppArmor: REJECTING r access to /home/sarnold (mozilla-bin(3029) - profile /usr/lib/mozilla-1.4/mozilla-bin active - /usr/lib/mozilla-1.4/mozilla-bin) - AppArmor: REJECTING rw access to /dev/pts/4 (sh(1721) - profile /usr/bin/crontab active /usr/bin/crontab) The permissions requested by the process are immediately after REJECTING. The "name" and process id of the running program are reported, @@ -117,18 +118,21 @@ active (see change_hat(2)) then the profile name is printed for "active". For confined processes running under a profile that has been loaded in complain mode, enforcement will not take place and the log messages -reported to klogd will be of the form: +reported to audit will be of the form: - AppArmor: PERMITTING r access to /root/.viminfo (vi(1272) - profile /bin/vim active /bin/vim) - AppArmor: PERMITTING w access to /root/.viminfo.tmp (vi(1272) - profile /bin/vim active /bin/vim) - AppArmor: PERMITTING wl access to /root/.viminfo (vi(1272) - profile /bin/vim active /bin/vim) - AppArmor: PERMITTING rwl access to /root/.viminfo.tmp (vi(1272) - profile /bin/vim active /bin/vim) - AppArmor: PERMITTING w access to /root/.viminfo (vi(1272) - profile /bin/vim active /bin/vim) + audit(1146868287.904:237): PERMITTING r access to + /etc/apparmor.d/tunables (du(3811) profile /usr/bin/du active + /usr/bin/du) + + audit(1146868287.904:238): PERMITTING r access to /etc/apparmor.d + (du(3811) profile /usr/bin/du active /usr/bin/du) + + +If the userland auditd is not running, the kernel will send audit events +to klogd; klogd will send the messages to syslog, which will log the +messages with the KERN facility. Thus, REJECTING and PERMITTING messages +may go to either F or F, +depending upon local configuration. =head1 FILES @@ -138,16 +142,19 @@ reported to klogd will be of the form: =item F -=item F - =item F +=item F + +=item F + =back =head1 SEE ALSO apparmor_parser(8), change_hat(2), apparmor.d(5), -subdomain.conf(5), autodep(1), clean(1), apparmor.vim(5), +subdomain.conf(5), autodep(1), clean(1), +auditd(8), unconfined(8), enforce(1), complain(1), and L. diff --git a/docs/apparmor_parser.pod b/docs/apparmor_parser.pod index 64cee389d..1291a64af 100644 --- a/docs/apparmor_parser.pod +++ b/docs/apparmor_parser.pod @@ -57,14 +57,14 @@ its input. It reports when an addition succeeded. =item -r, --replace This flag is required if an AppArmor definition by the same name already -exists in the kernel, and one wants to replace the definition already -in the kernel with the definition giving on standard input. +exists in the kernel; used to replace the definition already +in the kernel with the definition given on standard input. =item -R, --remove This flag is used to remove an AppArmor definition already in the kernel. Note that it still requires a complete AppArmor definition as described -in subdomain.d(5) even though the contents of the definition aren't +in apparmor.d(5) even though the contents of the definition aren't used. =item -p, --preprocess diff --git a/docs/genprof.pod b/docs/genprof.pod index c8c658d4b..9067e48aa 100644 --- a/docs/genprof.pod +++ b/docs/genprof.pod @@ -54,11 +54,10 @@ Genprof will then: - write a mark to the system log - instruct the user to start the application to - be profiled in another window and exercise its functionality It then presents the user with two options, (S)can system log for entries -to add to profile and (D)one. +to add to profile and (F)inish. If the user selects (S)can or hits return, genprof will parse the complain mode logs and iterate through generated violations @@ -70,7 +69,7 @@ the updated profiles in complain mode and again prompt the user for (S)can and (D)one. This cycle can then be repeated as neccesary until all application functionality has been exercised without generating access violations. -When the user eventually hits (D)one, genprof will set the main profile, +When the user eventually hits (F)inish, genprof will set the main profile, and any other profiles that were generated, into enforce mode and exit. =head1 BUGS diff --git a/docs/logprof.pod b/docs/logprof.pod index 4173f5abe..e287cf160 100644 --- a/docs/logprof.pod +++ b/docs/logprof.pod @@ -49,7 +49,7 @@ B< -m --logmark "mark"> =head1 DESCRIPTION -B is an interactive tool used to review AppArmor's syslog +B is an interactive tool used to review AppArmor's complain mode output and generate new entries for AppArmor security profiles. @@ -64,7 +64,7 @@ those processes are set to run under their proper profiles. =head2 Responding to AppArmor Events -B will generate a list of "suggested profile changes" that +B will generate a list of suggested profile changes that the user can choose from, or they can create their own, to modifiy the permission set of the profile so that the generated access violation will not re-occur. @@ -118,12 +118,12 @@ updated profiles to the disk and reload them if AppArmor is running. =head2 New Process (Execution) Events -If there are unhandled x accesses generated by the forking of a +If there are unhandled x accesses generated by the execve(2) of a new process, logprof will display the parent profile and the target program that's being executed and prompt the user to select and execute modifier. These modifiers will allow a choice for the target to: have it's own profile (px), inherit the parent's profile (ix), run unconstrained -(ux), or deny access for the target. +(ux), or deny access for the target. See apparmor.d(5) for details. If there is a corresponding entry for the target in the qualifiers section of /etc/logprof.conf, the presented list will contain only the @@ -142,7 +142,7 @@ logprof will never suggest "ux" as the default. =head2 ChangeHat Events -If unknown changehat events are found, the user is prompted to add a new +If unknown change_hat(2) events are found, the user is prompted to add a new hat, if the events should go into the default hat for this profile based on the corresponding entry in the defaulthat section of logprof.conf, or if the following events that run under that hat should be denied @@ -152,7 +152,7 @@ altogether. If there are capability accesses, the user is shown each capability access and asked if the capability should be allowed, denied, or if the -user wants to quit. +user wants to quit. See capability(7) for details. =head1 BUGS