mir/apparmor
2
0
Fork 0
mirror of https://gitlab.com/apparmor/apparmor synced 2025-08-30 22:05:27 +00:00
Code Issues Releases Wiki Activity

some cleanups, clarifications, that weren't checked in when written, for whatever reason..

Browse Source
This commit is contained in:
Seth Arnold
2006-11-03 09:47:55 +00:00
parent c0174cd7d4
commit c54f73f67f
4 changed files with 43 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

57
docs/apparmor.pod
View File

@@ -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<enforcement>, and I<complain or learning>:
@@ -56,7 +55,7 @@ policy violation attempts to syslogd.
I<complain> - Profiles loaded in C<complain> 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</etc/apparmor.d/>
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</usr/sbin/sshd> profile would be named F<usr.sbin.sshd>).
(e.g. the F</usr/sbin/nscd> profile would be named F<usr.sbin.nscd>).
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</var/log/audit/audit.log> or F</var/log/messages>,
depending upon local configuration.
=head1 FILES
@@ -138,16 +142,19 @@ reported to klogd will be of the form:
=item F</etc/apparmor.d/>
=item F</usr/share/vim/current/syntax/apparmor.vim>
=item F</lib/apparmor/>
=item F</var/log/audit/audit.log>
=item F</var/log/messages>
=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<http://forge.novell.com/modules/xfmod/project/?apparmor>.

6
docs/apparmor_parser.pod
View File

@@ -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

5
docs/genprof.pod
View File

@@ -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

12
docs/logprof.pod
View File

@@ -49,7 +49,7 @@ B< -m --logmark "mark">
=head1 DESCRIPTION
B<logprof> is an interactive tool used to review AppArmor's syslog
B<logprof> 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<logprof> will generate a list of "suggested profile changes" that
B<logprof> 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