mir/apparmor
2
0
Fork 0
mirror of https://gitlab.com/apparmor/apparmor synced 2025-09-01 06:45:38 +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 start
# /etc/init.d/boot.apparmor stop # /etc/init.d/boot.apparmor stop
# /etc/init.d/boot.apparmor restart # /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>: 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. I<complain> - Profiles loaded in C<complain> mode will not enforce policy.
Instead, it will report policy violation attempts. This mode is convenient for Instead, it will report policy violation attempts. This mode is convenient for
developing profiles. To manage complain mode for individual profiles the 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. 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/> Profiles are traditionally stored in files in F</etc/apparmor.d/>
under filenames with the convention of replacing the B</> in pathnames under filenames with the convention of replacing the B</> in pathnames
with B<.> (except for the root B</>) so profiles are easier to manage 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 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. 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 =head1 ERRORS
When a confined process tries to access a file it does not have permission 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 The permissions requested by the process are immediately after
REJECTING. The "name" and process id of the running program are reported, 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 For confined processes running under a profile that has been loaded in
complain mode, enforcement will not take place and the log messages 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) audit(1146868287.904:237): PERMITTING r access to
profile /bin/vim active /bin/vim) /etc/apparmor.d/tunables (du(3811) profile /usr/bin/du active
AppArmor: PERMITTING w access to /root/.viminfo.tmp (vi(1272) /usr/bin/du)
profile /bin/vim active /bin/vim)
AppArmor: PERMITTING wl access to /root/.viminfo (vi(1272) audit(1146868287.904:238): PERMITTING r access to /etc/apparmor.d
profile /bin/vim active /bin/vim) (du(3811) profile /usr/bin/du active /usr/bin/du)
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) If the userland auditd is not running, the kernel will send audit events
profile /bin/vim active /bin/vim) 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 =head1 FILES
@@ -138,16 +142,19 @@ reported to klogd will be of the form:
=item F</etc/apparmor.d/> =item F</etc/apparmor.d/>
=item F</usr/share/vim/current/syntax/apparmor.vim>
=item F</lib/apparmor/> =item F</lib/apparmor/>
=item F</var/log/audit/audit.log>
=item F</var/log/messages>
=back =back
=head1 SEE ALSO =head1 SEE ALSO
apparmor_parser(8), change_hat(2), apparmor.d(5), 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 unconfined(8), enforce(1), complain(1), and
L<http://forge.novell.com/modules/xfmod/project/?apparmor>. 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 =item -r, --replace
This flag is required if an AppArmor definition by the same name already 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 exists in the kernel; used to replace the definition already
in the kernel with the definition giving on standard input. in the kernel with the definition given on standard input.
=item -R, --remove =item -R, --remove
This flag is used to remove an AppArmor definition already in the kernel. This flag is used to remove an AppArmor definition already in the kernel.
Note that it still requires a complete AppArmor definition as described 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. used.
=item -p, --preprocess =item -p, --preprocess

5
docs/genprof.pod
View File

@@ -54,11 +54,10 @@ Genprof will then:
- write a mark to the system log - write a mark to the system log
- instruct the user to start the application to - instruct the user to start the application to
be profiled in another window and exercise its functionality be profiled in another window and exercise its functionality
It then presents the user with two options, (S)can system log for entries 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 If the user selects (S)can or hits return, genprof will parse
the complain mode logs and iterate through generated violations 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 (D)one. This cycle can then be repeated as neccesary until all application
functionality has been exercised without generating access violations. 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. and any other profiles that were generated, into enforce mode and exit.
=head1 BUGS =head1 BUGS

12
docs/logprof.pod
View File

@@ -49,7 +49,7 @@ B< -m --logmark "mark">
=head1 DESCRIPTION =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 complain mode output and generate new entries for AppArmor security
profiles. profiles.
@@ -64,7 +64,7 @@ those processes are set to run under their proper profiles.
=head2 Responding to AppArmor Events =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 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 permission set of the profile so that the generated access violation
will not re-occur. 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 =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 new process, logprof will display the parent profile and the target
program that's being executed and prompt the user to select and execute 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 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 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 If there is a corresponding entry for the target in the qualifiers
section of /etc/logprof.conf, the presented list will contain only the 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 =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 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, on the corresponding entry in the defaulthat section of logprof.conf,
or if the following events that run under that hat should be denied 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 If there are capability accesses, the user is shown each capability
access and asked if the capability should be allowed, denied, or if the 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 =head1 BUGS