[apparmor] apparmor chapter - not finished
John Johansen
john.johansen at canonical.com
Thu Jan 23 14:03:43 UTC 2014
On 01/20/2014 09:25 AM, Christian Boltz wrote:
> Hello,
>
> Am Freitag, 17. Januar 2014 schrieb Tomáš Bažant:
>> > [...]
> For those not following #apparmor in the last days/weeks:
> Tomáš is currently updating the AppArmor manual for SLE (which will also
> end up in openSUSE).
>
> I'm responding on the ML to give everybody a chance to review it.
> You can checkout the current version with
> svn co https://svn.opensuse.org/svn/opensuse-doc/trunk/documents/sle/en
> (then check xml/apparmor_*)
>
> The attached file contains my review as a patch that can be applied to
> the SVN checkout (I diffed against r11911). Note that my patch adds
> several comments etc., so it's probably not a good idea to blindly apply
> it and commit the result to SVN ;-)
> (I'd recommend to apply it, then use something like meld to review it.)
>
> @John: Please search the patch for "John" and add your 0,02 $ - there
> are some details that I don't know good enough.
> (If someone else wants to comment, that's of course also welcome ;-)
>
> @Tomáš: {,you'll} have a lot of fun while fixing what I found ;-)
>
>
> Regards,
>
> Christian Boltz
>
> PS: non-random sig ;-)
> -- Yes, I know how much devs hate writing documentation... I was a dev. [Carlos E. R. in opensuse-factory]
>
>
> sle-apparmor-doc-notes.diff
>
>
> Index: xml/apparmor_changehat.xml
> ===================================================================
> --- xml/apparmor_changehat.xml (Revision 11911)
> +++ xml/apparmor_changehat.xml (Arbeitskopie)
> @@ -8,7 +8,7 @@
> <chapter id="cha.apparmor.hat">
> <title>Profiling Your Web Applications Using ChangeHat</title>
> <para>
> - A &aareg; profile represents the security policy for an individual program
> + An &aareg; profile represents the 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 <quote>change hats</quote> to use a different security
> @@ -23,6 +23,7 @@
> request to the &aa; module to switch security domains at arbitrary times
> during the application execution. Two examples for ChangeHat-aware
> applications are the Apache Web server and Tomcat.
> +<!-- the tomcat part is unmaintained in AppArmor, and I have no idea if it still works (John, any idea?) -->
Its out of date. It should still work with tomcat 5 and tomcat 5_5 but as far
as I know it doesn't work with tomcat 6, 7, or 8.
> </para>
> <para>
> A profile can have an arbitrary number of subprofiles, but there are only
> @@ -30,6 +31,9 @@
> is written as a separate profile and named as the containing profile
> followed by the subprofile name, separated by a <literal>^</literal>.
> Subprofiles must be stored in the same file as the parent profile.
> +<!-- untested: In theory, you can store hats in separate files with
> + /usr/sbin/httpd2_prefork//somehat
> + John, does this work in practise? -->
yes this works and is in use in some installs with a rather large number
of hats. As it allows the policy caching to handle changes at the
per hat level, where if all the hats are in the same file as the parent
then, the parent profile and all hats must be recompiled.
External subprofiles don't need anything special, but if the are going
to be used as a hat they must be begun with 'hat' or '^'
eg. child/subprofile that can not be used as a hat
/foo//bar { }
or
profile /foo//bar { }
where a hat needs to be
^/foo//bar { }
or
hat /foo//bar { }
> </para>
> <para>
> Note that the security of hats is considerably weaker than that of full
> @@ -220,6 +224,7 @@
> walks you through a real life example of creating a hat for a Web
> application, and making use of &aa;'s change_hat feature to secure it.
> Note that I am going to use &aa;'s command line tools, as &yast; &aa;
> +<!-- huh? that's the first time the manual talks to me ("I") ;-) -->
> module has limited functionality.
> </para>
>
> @@ -348,6 +353,7 @@
> it. It is time to create the related hat for Adminer in the &aa;
> configuration. &aa; comes with a number of ready profiles for frequently
> used applications - such as Apache. Because Apache's main binary is
> +<!-- AFAIK there's no profile shipped for apache, only an (outdated?) profile in the extras directory -->
> <filename>/usr/sbin/httpd2-prefork</filename>, let us focus on its
> related profile
> <filename>/etc/apparmor.d/usr.sbin.httpd2-prefork</filename>.
> @@ -373,13 +379,15 @@
> capability setuid,
>
> /etc/** r,
> +<!-- huh? /etc/** looks too broad -->
> /run/httpd.pid rw,
> /usr/lib{,32,64}/** mr,
> +<!-- huh? /usr/lib../** also looks too broad -->
> /var/log/apache2/** rw,
>
> ^DEFAULT_URI {
> #include <abstractions/apache2-common>
> - deny /srv/www/htdocs/adminer/adminer.php r,
> + deny /srv/www/htdocs/adminer/adminer.php r, <!-- huh? -->
> /var/log/apache2/** rw,
> }
>
> @@ -398,8 +406,11 @@
> }</screen>
> <para>
> Note the <literal>(complain)</literal> addition after the hat name - it
> - tells &aa; to leave the adminer hat in a complain mode. That is because
> + tells &aa; to leave the adminer hat in complain mode. That is because
> we need to learn the hat profile by accessing Adminer later on.
> +<!-- did you test this yourself? I remember a bug on older versions that caused some problems
> + when the main profile was enforced and only a hat in complain mode, but maybe this was
> + accidently ;-) fixed in the meantime -->
> </para>
> </step>
> <step>
> @@ -435,7 +446,7 @@
>
> <para>
> Our last task is to find out the right set of rules for the adminer hat.
> - That is why we set the adminer hat into a complain mode - the logging
> + That is why we set the adminer hat into complain mode - the logging
> facility collects useful information about
> <filename>adminer.php</filename>'s access requirements as we use it via
> the Web browser. <command>aa-logprof</command> then helps us with
> @@ -446,7 +457,7 @@
> <title>Generating Rules for the Adminer Hat</title>
> <step>
> <para>
> - Open Adminer in the Web browser. If you installed it locally, the the
> + Open Adminer in the Web browser. If you installed it locally, the the <!-- "then the"? -->
> URI is <literal>http://localhost/adminer/adminer.php</literal>.
> </para>
> </step>
> @@ -465,6 +476,8 @@
> console and examine the log for collected data.
> </para>
> <screen># aa-logprof usr.sbin.httpd2-prefork
> +<!-- ^^^^^^^^^^^^^^^^^^^^^^^ this parameter is superfluous and ignored
> + aa-logprof always works on all profiles -->
> Reading log entries from /var/log/messages.
> Updating AppArmor profiles in /etc/apparmor.d.
> Complain-mode changes:
> @@ -474,7 +487,8 @@
> Mode: r
> Severity: 3
>
> - 1 - #include &abstractions/apache2-common>
> + 1 - #include &abstractions/apache2-common>
> + <!-- ^^^^^ wrong, should be < -->
> [...]
> [8 - /dev/urandom]
>
> Index: xml/apparmor_glossary.xml
> ===================================================================
> --- xml/apparmor_glossary.xml (Revision 11911)
> +++ xml/apparmor_glossary.xml (Arbeitskopie)
> @@ -9,6 +9,12 @@
> <chapter id="cha.apparmor.glossary">
> <title>&aa; Glossary</title>
> <variablelist>
> +
> +<!-- please add:
> + - Abstraction -> see "profile foundation classes"
> + - Profile (or AppArmor Profile) - definition to be written
> +-->
> +
> <varlistentry>
> <term>Apache</term>
> <listitem>
> @@ -25,6 +31,7 @@
> <listitem>
> <para>
> &aa; contains applications and limits the actions they are permitted to
> + <!-- ^^^^^^^^ "confines"? -->
> take. It uses privilege confinement to prevent attackers from using
> malicious programs on the protected server and even using trusted
> applications in unintended ways.
> @@ -65,6 +72,7 @@
> <listitem>
> <para>
> Filename substitution.
> +<!-- should mention things like "*" and "?" in the explanation -->
> </para>
> </listitem>
> </varlistentry>
> @@ -160,6 +168,7 @@
> </para>
> <para>
> For example, in <literal>http://www.novell.com</literal>, http is the
> +<!-- what about using www.suse.com instead? ;-) -->
> protocol to use.
> </para>
> </listitem>
> Index: xml/apparmor_intro.xml
> ===================================================================
> --- xml/apparmor_intro.xml (Revision 11911)
> +++ xml/apparmor_intro.xml (Arbeitskopie)
> @@ -30,6 +30,12 @@
> Also see bnc #722915
>
> -->
> +
> +
> +<!-- general note for all chapters:
> + - Line breaks often contain "Ap-pArmor" - should be "App-Armor"
> +-->
> +
> <chapter id="cha.apparmor.intro">
> <title>Introducing &aa;</title>
> <para>
> @@ -78,11 +84,13 @@
> Several specially modified applications that are &aa; enabled to provide
> enhanced security in the form of unique subprocess confinement
> (including Apache and Tomcat).
> +<!-- the Tomcat part is unmaintained -->
> </para>
> </listitem>
> <listitem>
> <para>
> The &aa;–loadable kernel module and associated control scripts to
> + <!-- AFAIK it's built into the kernel, so "loadable module" might be confusing -->
> enforce &aa; policies on your
> <phrase
> os="sles;sled;osuse">&productnamereg;</phrase><phrase
> Index: xml/apparmor_managing.xml
> ===================================================================
> --- xml/apparmor_managing.xml (Revision 11911)
> +++ xml/apparmor_managing.xml (Arbeitskopie)
> @@ -16,6 +16,8 @@
> profiles, backing up your set of profiles and keeping it up-to-date). You
> can deal with these issues before they become a problem by setting up
> event notification by e-mail, running periodic reports, updating profiles
> + <!-- ^^^^^^^^^^^^^^^^^^^^^^^^ remove this part, see comment below
> + or include a note about setting up an aa-notify cronjob (as described in apparmor_intro.xml) -->
> from system log entries by running the aa-logprof tool through &yast;, and
> dealing with maintenance issues.
> </para>
> @@ -1710,6 +1712,13 @@
> </sect1>
> -->
> <!-- fs 2011-11-09 - see bnc #722915
> +
> +Please make the section about aa-notify visible and expand it.
> +aa-notify basically can do two things:
> +a) provide a summary of events (for example for a daily cronjob)
> +b) desktop notifications
> +
> +
> The Gnome desktop applet is obsolete. It was replaced by aa-notify, which can
> be started with:
> sudo DISPLAY=$DISPLAY /usr/sbin/aa-notify -p
> Index: xml/apparmor_profiles.xml
> ===================================================================
> --- xml/apparmor_profiles.xml (Revision 11911)
> +++ xml/apparmor_profiles.xml (Arbeitskopie)
> @@ -119,8 +119,8 @@
> <screen>#include <tunables/global><co id="co.apparmor.profiles.vardef"/>
>
> # a comment naming the application to confine
> -/usr/bin/foo<co id="co.apparmor.profiles.path"/>
> -{<co id="co.apparmor.profiles.brack"/>
> +/usr/bin/foo<co id="co.apparmor.profiles.path"/> {<co id="co.apparmor.profiles.brack"/>
> +<!-- "/usr/bin/foo {" should be one line -->
> #include <abstractions/base><co id="co.apparmor.profiles.incl"/>
>
> capability setgid<co id="co.apparmor.profiles.capent"/>,
> @@ -141,12 +141,12 @@
> /@{HOME}<co id="co.apparmor.profiles.variable"/>/.foo_file rw,
> /@{HOME}/.foo_lock kw,
> owner<co id="co.apparmor.profiles.owner"/> /shared/foo/** rw,
> - /usr/bin/foobar cx,<co id="co.apparmor.profiles.cx"/>
> - /bin/** px -> bin_generic,<co id="co.apparmor.profiles.named"/>
> + /usr/bin/foobar Cx,<co id="co.apparmor.profiles.cx"/>
> + /bin/** Px -> bin_generic,<co id="co.apparmor.profiles.named"/>
> +<!-- examples should have uppercase Cx and Px (more secure) -->
>
> + # a comment about foo's local (children) profile for /usr/bin/foobar.
>
> - # a comment about foo's local (children)profile for /usr/bin/foobar.
> -
> profile /usr/bin/foobar<co id="co.apparmor.profiles.local"/> {
> /bin/bash rmix,
> /bin/cat rmix,
> @@ -306,6 +306,7 @@
> <systemitem
> class="resource">audit</systemitem> package is installed
> or otherwise in <filename>/var/log/messages</filename>. In many cases,
> +<!-- or only in journalctl if no traditional syslog is installed -->
> &aa; rules prevent an attack from working because necessary files are not
> accessible and, in all cases, &aa; confinement restricts the damage that
> the attacker can do to the set of files permitted by &aa;.
> @@ -360,7 +361,7 @@
> }</screen>
> <para>
> Unattached profiles are never used automatically, nor can they be
> - transitioned to through a <literal>px</literal> rule. They need to be
> + transitioned to through a <literal>Px</literal> rule. They need to be
> attached to a program by either using a named profile transition (see
> <xref linkend="sec.apparmor.profiles.exec.named"/>) or with the
> <literal>change_profile</literal> rule (see
> @@ -386,6 +387,7 @@
> <screen>/parent/profile {
> ...
> profile local/profile {
> + <!-- should this be /local/profile ? -->
> ...
> }
> }</screen>
> @@ -478,6 +480,9 @@
> By default, &aa; adds <filename>/etc/apparmor.d</filename> to the path in
> the <literal>#include</literal> statement. &aa; expects the include files
> to be located in <filename>/etc/apparmor.d</filename>. Unlike other
> +<!-- and/or relative to the profile ;-)
> + There are some subtile differences and slightly different syntax you can use with #include - John, can you explain them, please?
> + Besides that, "include" without the # will also work -->
first up there is the unfortunate overlap of comments and includes,
that is comments begin with # and includes also can begin #include.
because of this #include is only treated as an include if
- there is not a preceeding #
##include is a comment
- there is NO whitespace between # and include
# include is a comment
include without the leading # has been accepted for several releases
now as a way to specify an include
include <foo> # this is the same as using #include
notice because includes follow the C preprocessor syntax that includes
do not have a trailing ',' like most rules.
so to the behavior of includes, the use of "" specifies do an absolute
or relative path lookup.
include "/etc/apparmor.d/foo" # absolute path
include "foo" # relative path to dir of current file
Note for relative paths the once a file is included it is considered the
current file for its includes
So say you are in /etc/apparmor.d/foo
include "abstractions/bar" # includes /etc/apparmor.d/abstractions/bar
If bar then does
include "example" # includes /etc/apparmor.d/abstractions/example
the use of < > specifies to try the include path (specified by -I,
defaulting to /etc/apparmor.d) in order
So assuming the include path is -I /etc/apparmor.d/ -I /usr/share/apparmor/
include <abstractions/foo>
with try
/etc/apparmor.d/abstractions/foo
and if that doesn't exist, try
/usr/share/apparmor/abstractions/foo
the default Include path can be overridden manually by passing -I to
the apparmor_parser or by setting the include paths in the
/etc/apparmor/parser.conf
file. Eg.
Include /usr/share/apparmor/
Include /etc/apparmor.d/
multiple entries are allowed and they are taken in order just like
for -I or --Include from the apparmor_parser command line.
Finally if an include ends with '/', this is considered a directory
include and all files within the directory are included
include "local/"
will include all files (well it skips dot files and a few blacklisted
suffixes like .rpm_new) dropped into the local/ directory
> profile statements (but similar to C programs),
> <literal>#include</literal> lines do not end with a comma.
> </para>
> @@ -568,6 +573,9 @@
> <literal>sna</literal>, <literal>irda</literal>,
> <literal>pppox</literal>, <literal>wanpipe</literal>,
> <literal>bluetooth</literal>
> + <!-- full list: unspec unix inet ax25 ipx appletalk netrom bridge atmpvc x25 inet6 rose netbeui security key netlink packet ash econet atmsvc rds sna irda pppox wanpipe llc can tipc bluetooth iucv rxrpc isdn phonet ieee802154 caif alg nfc vsock
> +(list grabbed from apparmor.vim, which gets it during build via Makefile magic)
> +(not sure if "unspec" is really allowed - John?) -->
It seems it is, though I think I would consider that a bug
> </para>
> </callout>
> <callout arearefs="co.apparmor.profiles.nac.type">
> @@ -603,8 +611,9 @@
> The &aa; tools support only family and type specification. The &aa;
> module emits only <literal>network <replaceable>domain</replaceable>
> <replaceable>type</replaceable></literal> in <quote>access denied</quote>
> - messages. And only these are output by the profile generation tools, both
> - &yast; and command line.
> + messages. And only these are output by the profile generation tools.
> + <!--, both
> + &yast; and command line. -->
> </para>
>
> <para>
> @@ -661,7 +670,7 @@
> <title>Profile Names, Paths, and Globbing</title>
>
> <para>
> - Profile is usually attached to a program by specifying a full path to the
> + A profile is usually attached to a program by specifying a full path to the
> program's executable. For example in the case of a standard profile (see
> <xref
> linkend="sec.apparmor.profiles.types.attached"/>), the profile
> @@ -714,6 +723,7 @@
> <listitem>
> <para>
> Give read access to any directories below <filename>/some</filename>.
> +(but not /some/ itsself)
> </para>
> </listitem>
> </varlistentry>
> @@ -724,6 +734,7 @@
> <para>
> Give read access to files and directories under
> <filename>/some/random/example</filename>.
> +(but not /some/random/example/ itsself)
> </para>
> </listitem>
> </varlistentry>
> @@ -892,6 +903,11 @@
> @{CHROOT_BASE}/var/log/** w,
> ...
> }</screen>
> +
> +<!-- please add another example with
> + @{FOO} += /some/thing
> + which _adds_ /some/thing to @{FOO}
> + -->
> <note>
> <para>
> With the current &aa; tools, variables can only be used when manually
> @@ -937,6 +953,7 @@
>
> <sect2 id="apparmor.profiles.namespaces">
> <title>Namespaces</title>
> + <!-- I'm not familiar with namespaces yet - John, please review this part -->
I'll comment is a separate reply
> <para>
> Namespaces are used to provide different profiles set. Say one for the
> system, another for a chroot environment or container. Namespaces are
> @@ -1015,6 +1032,12 @@
> original source path, use the <literal>rewrite</literal> rule.
> </para>
> <screen>rewrite /home/ -> /usr/home/</screen>
> +<!-- are you sure this is different from "alias"? (John?)
theoretically yes, but it hasn't been implemented yet and maps to the wider
alias rule atm.
Atm I would just drop rewrite from the documentation
> + It seems to be mapped to the same...
> +
> + parser_misc.c: {"alias", TOK_ALIAS},
> + parser_misc.c: {"rewrite", TOK_ALIAS},
> + -->
> </tip>
> <para>
> With the <literal>alias</literal> rule (not valid for
> @@ -1028,6 +1051,7 @@
> With the current &aa; tools, alias rules can only be used when manually
> editing and maintaining a profile. Whats more, they are deactivated by
> disabled. Enable alias rules by editing
> +<!-- what does "they are deactivated by disabled" mean? That's at least confusing. -->
> <filename>/etc/apparmor.d/tunables/alias</filename>
> </para>
> </note>
> @@ -1189,6 +1213,7 @@
> <screen>/link l,
> link subset /link -> /**,
> </screen>
> +<!-- having an example of a very simple link rule would be nice -->
> <note>
> <para>
> Currently link pair rules are not supported by &yast; and the command
> @@ -1227,6 +1252,7 @@
> The following rule grants access to all files:
> </para>
> <screen>file,</screen>
> +<!-- please add a note "file, is equal to /** rwkl," (IIRC - John, is this correct?) -->
currently I think /** rwmlk, I will have to double check.
But that could change to a wider set of perms in the future.
It is supposed to be the widest set of file permissions not
including domain transitions.
> <para>
> File rules can use leading or trailing permissions. The permissions do
> not need to be specified as a trailing permission, but rather used at
> @@ -1262,10 +1288,19 @@
> Owner conditional rules are considered a subset of regular file rules.
> If a regular file rule overlaps with an owner conditional file rule,
> the resultant permissions will be that of the regular file rule.
> +<!-- wrong - the rules are merged ;-)
> + example:
> + /foo r,
> + owner /foo rw, # or just w,
> +
> + means r for everybody and w just for the owner
> + -->
> </para>
> </note>
> </sect2>
>
> +<!-- there's also the 'other' keyword - meaning: "not the owner" -->
> +
> <sect2 id="sec.apparmor.profiles.perm.deny">
> <title>Deny Rules</title>
> <para>
> @@ -1291,6 +1326,7 @@
> judicious use of deny rules can simplify profiles. Therefore the tools
> only generate profiles denying specific files and will not make use of
> globbing in deny rules. Manually edit your profiles to add deny rules
> +<!-- personally, I'd call that a bug in the tools ;-) - John? -->
you could call it that. Basically its a this is as far as we got implementing
the feature
> using globbing. Updating such profiles using the tools is safe, because
> the deny entries will not be touched.
> </para>
> @@ -1374,6 +1410,9 @@
>
> <sect2 id="sec.apparmor.profiles.exec.px">
> <title>Discrete Profile Execute Mode (px)</title>
> +<!-- I'd prefer to have the uppercase Px listed as default everywhere (in the headlines, the table above etc.
> + This also means you can remove the <warning> sections (cx doesn't have one, BTW)
> + -->
> <para>
> This mode requires that a discrete security profile is defined for a
> resource executed at an &aa; domain transition. If there is no profile
> @@ -1425,6 +1464,7 @@
> rebooting the machine. By placing the privileged section in another
> executable and granting unconstrained execution rights, it is possible
> to bypass the mandatory constraints imposed on all confined processes.
> +<!-- I'm not sure if such constraints still exist (at least some were removed) - John? -->
ugh first up search and replace 'unconstrained' with 'unconfined'
so I can't think of any changes here that have landed yet. We do have work
to allow defining default profiles etc, but that hasn't landed yet.
u/Ux is just dangerous and generally shouldn't be used. The process runs
unconfined and has all the privileges of an unconfined process, but regular
unix DAC permissions still apply so, allowing a user process to go
unconfined just means it has no additional restrictions placed on it.
Allowing a root process to go unconfined means it can change policy, etc.
> For more information about what is constrained, see the
> <systemitem>apparmor(7)</systemitem> man page.
> </para>
> @@ -1449,6 +1489,7 @@
>
> <sect2 id="sec.apparmor.profiles.exec.clean">
> <title>Clean Exec modes</title>
> +<!-- if you follow my proposal from above, change this section to "unsafe exec modes" + basically the text from the <warning> -->
> <para>
> The clean exec modes allow the named program to run in
> <literal>px</literal>, <literal>cx</literal> and <literal>ux</literal>
> @@ -1544,6 +1585,7 @@
> <literal>Cx</literal>, <literal>px</literal> and <literal>Px</literal>.
> Currently there is a limit of twelve named profile transitions per
> profile.
> + <!-- John, does this limit still exist? -->
yes it does. I may get this fixed for the 3.0 release (Not yet out) but its
looking more and more like that will get pushed out to the 3.1 release.
> </para>
> <para>
> Named profile transitions use <literal>-></literal> to indicate the name
> @@ -1796,6 +1838,7 @@
> <listitem>
> <para>
> currently not supported
> +<!-- still valid? (John?) -->
cpu is actually supported now.
however nproc's behavior has changed from 2.3, this is due to changes in the
kernel.
In 2.3 nproc would keep a count per profile so there it would limit the
number of processes in a given profile. However it now just provides a
standard rlimit/ulimit nproc now. That is it controls the number of
processes/threads that a given user can create
> </para>
> </listitem>
> </varlistentry>
> @@ -1808,6 +1851,7 @@
> <para>
> a number in bytes, or a number with a suffix where the suffix can be K
> (kilobytes), M (megabytes), G (gigabytes), for example
> +<!-- can also be KB, MB, GB -->
> </para>
> <screen>rlimit data <= 100M,</screen>
> </listitem>
> @@ -1833,7 +1877,8 @@
> </listitem>
> </varlistentry>
> </variablelist>
> -
> +<!-- apparmor.vim has some rlimit additions pending - they are probably also missing in the documentation
> + See the ML for details -->
> <para>
> <superscript>*</superscript>The nproc rlimit is handled different than
> all the other rlimits. Instead of indicating the standard process rlimit
> @@ -1886,6 +1931,7 @@
> Audit control can be combined with owner conditional file rules to
> provide auditing when users access files they own (at the moment it is
> not possible to audit files they don't own):
> +<!-- see above - 'other' keyword -->
> </para>
>
> <screen>audit owner /home/*/.ssh/** rw,</screen>
> Index: xml/apparmor_profiles_man.xml
> ===================================================================
> --- xml/apparmor_profiles_man.xml (Revision 11911)
> +++ xml/apparmor_profiles_man.xml (Arbeitskopie)
> @@ -28,6 +28,7 @@
>
> <para>
> An &aa; module can be in any one of three states:
> + <!-- An? better "The" (and again, AFAIK it's always built-in) -->
> </para>
>
> <variablelist>
> @@ -103,6 +104,9 @@
> </varlistentry>
> <varlistentry>
> <term><command>rcapparmor restart</command>
> +<!-- change that to "rcapparmor reload" - behaviour of "restart" is broken with systemd (bnc#853019)
> + (change it everywhere where "restart" is mentioned, not only here ;-)
> + -->
> </term>
> <listitem>
> <para>
> @@ -164,6 +168,7 @@
> directory is not an effective way of preventing profiles from being
> loaded. You must remove profiles from this directory to prevent them from
> being read and evaluated effectively.
> +<!-- or call aa-disable, which will create a symlink in /etc/apparmor.d/disabled -->
> </para>
>
> <para>
> @@ -260,12 +265,12 @@
> </step>
> <step>
> <para>
> - Make the necessary, changes then save the profile.
> + Make the necessary changes, then save the profile.
> </para>
> </step>
> <step>
> <para>
> - Restart &aa; by entering <command>rcapparmor restart</command> in a
> + Restart &aa; by entering <command>rcapparmor reload</command> in a
> terminal window.
> </para>
> </step>
> @@ -309,7 +314,7 @@
> </step>
> <step>
> <para>
> - Restart &aa; by entering <command>rcapparmor restart</command> in a
> + Restart &aa; by entering <command>rcapparmor reload</command> in a
> terminal window.
> </para>
> </step>
> @@ -438,6 +443,7 @@
> <para>
> Activate learning or complain mode for all profiled programs by
> entering <command>aa-complain /etc/apparmor.d/*</command> in a
> +<!-- this gets a funny linebreak, see the PDF -->
> terminal window while logged in as &rootuser;. This functionality is
> also available through the &yast; Profile Mode module, described in
> <xref
> @@ -520,6 +526,7 @@
> This is when the system goes back to enforcing the rules of the
> profiles, not just logging information. This can be done manually by
> removing the <literal>flags=(complain)</literal> text from the
> +<!-- could also be a symlink in /etc/apparmor.d/force-complain/ -->
> profiles or automatically by using the <command>aa-enforce</command>
> command, which works identically to the <command>aa-complain</command>
> command, except it sets the profiles to enforce mode. This
> @@ -540,7 +547,7 @@
> </para>
> <para>
> To have &aa; rescan all of the profiles and change the enforcement
> - mode in the kernel, enter <command>rcapparmor restart</command>.
> + mode in the kernel, enter <command>rcapparmor reload</command>.
> </para>
> </step>
> </procedure>
> @@ -650,6 +657,7 @@
> Manually activating complain mode (using the command line) adds a flag
> to the top of the profile so that <literal>/bin/foo</literal> becomes
> <literal>/bin/foo flags=(complain)</literal>. To use complain mode,
> +<!-- or create a symlink in force-complain -->
> open a terminal window and enter one of the following lines as
> &rootuser;:
> </para>
> @@ -751,6 +759,10 @@
> Manually activating enforce mode (using the command line) adds a flag
> to the top of the profile so that <literal>/bin/foo</literal> becomes
> <literal>/bin/foo flags=(enforce)</literal>. To use enforce mode, open
> +<!-- there is no "enforce" flag - if a profile doesn't have the "complain" flag, it is in enforce mode.
> + You could write something like
> + ... so that /bin/foo flags=(complain) becomes /bin/foo
> + -->
> a terminal window and enter one of the following lines as &rootuser;.
> </para>
> <itemizedlist>
> @@ -774,7 +786,8 @@
> <replaceable>/etc/apparmor.d</replaceable>, use the following to
> override the default location:
> </para>
> -<screen>aa-enforce <replaceable>/path/to/profiles/program1</replaceable></screen>
> +<screen>aa-enforce -d <replaceable>/path/to/profiles/ program1</replaceable></screen>
> +<!-- (-d and space were missing) -->
> </listitem>
> <listitem>
> <para>
> @@ -863,6 +876,7 @@
> os="slert">&slert;</phrase>,
> the default full path is
> <filename>/usr/sbin/httpd2-prefork</filename>.
> +<!-- results in funny linebreak again -->
> </para>
> </listitem>
> <listitem>
> @@ -883,15 +897,18 @@
> </para>
> <screen>type=APPARMOR_ALLOWED msg=audit(1189682639.184:20816):
> operation="file_mmap" requested_mask="::r" denied_mask="::r" fsuid=30 name="/srv/www/htdocs/index.html" pid=27471 profile="null-12345" </screen>
> +<!-- looks like the old log format - the currently used format has some more fields -->
> <para>
> If you are not running the audit daemon, the &aa; events are logged
> to <filename>/var/log/messages</filename>:
> </para>
> <screen>Sep 13 13:20:30 K23 kernel: audit(1189682430.672:20810): operation="file_mmap" requested_mask="::r" denied_mask="::r" fsuid=30 name="/srv/www/htdocs/phpsysinfo/templates/bulix/form.tpl" pid=30405 profile="/usr/sbin/httpd2-prefork///phpsysinfo/"</screen>
> +<!-- also looks like the old log format -->
> <para>
> They also can be viewed using the <command>dmesg</command> command:
> </para>
> <screen>audit(1189682430.672:20810): operation="file_mmap" requested_mask="::r" denied_mask="::r" fsuid=30 name="/srv/www/htdocs/phpsysinfo/templates/bulix/form.tpl" pid=30405 profile="/usr/sbin/httpd2-prefork///phpsysinfo/"</screen>
> +<!-- also looks like the old log format -->
> </listitem>
> <listitem>
> <para>
> @@ -916,7 +933,7 @@
> <step>
> <para>
> Select from the following options that are available in the
> - <command>aa-logprof</command> terminal window after you have executed
> + <command>aa-genprof</command> terminal window after you have executed
> the program function:
> </para>
> <itemizedlist>
> @@ -923,6 +940,7 @@
> <listitem>
> <para>
> <keycap>S</keycap> runs <command>aa-logprof</command> on the system
> +<!-- aa-logprof intentional here? Even if yes, it might be confusing -->
> log from where it was marked when <command>aa-genprof</command> was
> started and reloads the profile. If system events exist in the log,
> &aa; parses the learning mode log files. This generates a series of
> @@ -933,6 +951,7 @@
> <listitem>
> <para>
> <keycap>F</keycap> exits the tool and returns to the main menu.
> +<!-- main menu??? -->
> </para>
> </listitem>
> </itemizedlist>
> @@ -993,6 +1012,7 @@
> Severity: unknown
>
> [(I)nherit] / (P)rofile / (U)nconfined / (D)eny / Abo(r)t / (F)inish
> +<!-- looks outdated, I'd also expect (C)hild -->
> </screen>
> </example>
> <variablelist>
> @@ -1009,11 +1029,12 @@
> such as the <command>/usr/bin/mail</command> client using
> <command>less</command> as a pager or the Mozilla* Web browser
> using Adobe Acrobat* to display PDF files.
> +<!-- please use supported software as example ;-) -->
> </para>
> </listitem>
> </varlistentry>
> <varlistentry>
> - <term>Profile (px)</term>
> + <term>Profile (px/Px)</term>
> <listitem>
> <para>
> The child runs using its own profile, which must be loaded into
> @@ -1031,7 +1052,7 @@
> </listitem>
> </varlistentry>
> <varlistentry>
> - <term>Unconfined (ux)</term>
> + <term>Unconfined (ux/Ux)</term>
> <listitem>
> <para>
> The child runs completely unconfined without any &aa; profile
> @@ -1043,9 +1064,11 @@
> could modify execution behavior when passed to the child
> process. This option introduces a security vulnerability that
> could be used to exploit &aa;. Only use it as a last resort.
> +<!-- that sounds like Ux introduces the security vulnerability... -->
> </para>
> </listitem>
> </varlistentry>
> +<!-- cx/Cx is missing -->
> <varlistentry>
> <term>mmap (m)</term>
> <listitem>
> @@ -1064,6 +1087,7 @@
> <para>
> Prevents the program from accessing the specified directory path
> entries. &aa; then continues to the next event.
> + <!-- also adds a "deny ..." rule to the profile, so you should place the word "permanently" somewhere ;-) -->
> </para>
> </listitem>
> </varlistentry>
> @@ -1096,6 +1120,8 @@
> </para>
> <example id="ex.apparmor.commandline.profiling.summary.genprof.perms">
> <title>Learning Mode Exception: Defining Execute Permissions for an Entry</title>
> +<!-- the headline doesn't match most parts of the example (except the first line)
> + I'd also recommend to use an example that acutally offers an abstraction and a globbed path -->
> <screen>Adding /bin/ps ix to profile.
>
> Profile: /usr/sbin/xinetd
> @@ -1270,7 +1296,7 @@
> <step>
> <para>
> Restart &aa; and reload the profile set including the newly created
> - one using the <command>rcapparmor <option>restart</option></command>
> + one using the <command>rcapparmor <option>reload</option></command>
> command.
> </para>
> </step>
> @@ -1280,6 +1306,7 @@
> Profile Wizard, <command>aa-genprof</command> also supports the use of
> the local profile repository under
> <filename>/etc/apparmor/profiles/extras</filename><phrase os="sles;osuse;sled">
> +<!-- path will change in &aa; ;-) 3.0 -->
> and the remote &aa; profile repository</phrase>.
> </para>
> <para>
> @@ -1325,6 +1352,8 @@
> </step>
> </procedure>
> <para os="sles;sled;osuse">
> +<!-- the online repo is down, please remove (or comment) this section -->
> +<!--
> To use the remote &aa; profile repository with
> <command>aa-genprof</command>, proceed as follows:
> </para>
> @@ -1412,6 +1441,8 @@
> </para>
> </step>
> </procedure>
> +[END online repo]
> +-->
> </sect3>
> <sect3 id="sec.apparmor.commandline.profiling.summary.logprof">
> <title>aa-logprof—Scanning the System Log</title>
> @@ -1418,13 +1449,16 @@
> <para>
> <command>aa-logprof</command> is an interactive tool used to review the
> learning or complain-mode output found in the log entries in
> +<!-- also handles enforce mode events -->
> <filename>/var/log/audit/audit.log</filename> or
> <filename>/var/log/messages</filename> (if auditd is not running) and
> +<!-- or journalctl, but aa-logprof doesn't look there -->
> generate new entries in &aa; security profiles.
> </para>
> <para>
> When you run <command>aa-logprof</command>, it begins to scan the log
> files produced in learning or complain mode and, if there are new
> +<!-- also handles enforce mode events -->
> security events that are not covered by the existing profile set, it
> gives suggestions for modifying the profile. The learning or complain
> mode traces program behavior and enters it in the log.
> @@ -1438,8 +1472,9 @@
> execution modes <emphasis>ix</emphasis>, <emphasis>px</emphasis>,
> <emphasis>Px</emphasis>, <emphasis>ux</emphasis>, and
> <emphasis>Ux</emphasis> are options for starting the child process. If
> +<!-- and cx/Cx and named profile -->
> a separate profile exists for the child process, the default selection
> - is <emphasis>px</emphasis>. If one does not exist, the profile defaults
> + is <emphasis>Px</emphasis>. If one does not exist, the profile defaults
> to <emphasis>ix</emphasis>. Child processes with separate profiles have
> <command>aa-autodep</command> run on them and are loaded into &aa;, if
> it is running.
> @@ -1528,7 +1563,7 @@
> By default, <command>aa-logprof</command> looks for profiles in
> <filename>/etc/apparmor.d/</filename> and scans the log in
> <filename>/var/log/messages</filename>. In many cases, running
> - <command>aa-logprof</command> as &rootuser; is enough to create the
> + <command>aa-logprof</command> as &rootuser; is enough to update the
> profile.
> </para>
> <para>
> @@ -1595,6 +1630,8 @@
> <listitem>
> <para>
> Prevents the program from accessing the specified directory path
> +<!-- permanently
> + (or just copy&paste the whole section from aa-genprof and s/genprof/logprof/ ;-) -->
> entries. &aa; then continues to the next event.
> </para>
> </listitem>
> @@ -1667,6 +1704,9 @@
> </para>
> <screen>Profile: /usr/sbin/vsftpd
> Path: /y2k.jpg
> +<!-- will probably be displayed as /path/to/chroot/y2k.jpg nowadays
> +See also the chroot_relative flag.
> + -->
> New Mode: r
>
> [1 - /y2k.jpg]
> @@ -1682,8 +1722,9 @@
> vsftpd on
> <phrase os="sles;sled;osuse">&productname;</phrase><phrase
> os="slert">&slert;</phrase>
> +<!-- without chroot_relative, you'll get /path/to/chroot/y2k.jpg, so you need to rewrite the whole section -->
> serves FTP files from <filename>/srv/ftp</filename> by default. This is
> - because httpd2-prefork uses chroot and, for the portion of the code
> + because vsftpd uses chroot and, for the portion of the code
> inside the chroot jail, &aa; sees file accesses in terms of the chroot
> environment rather than the global absolute path.
> </para>
> @@ -1725,6 +1766,7 @@
> prompt:
> </para>
> <screen>
> +<!-- without having checked it, I'm quite sure this screen looks different nowadays. Also, (C)hild is missing -->
> /usr/bin/nail -> /usr/bin/less
> (I)nherit / (P)rofile / (U)nconfined / (D)eny
> </screen>
> @@ -1774,18 +1816,20 @@
> <filename>/usr/bin/mail</filename> runs
> <filename>/usr/bin/less</filename> in this context, the less program
> is far less dangerous than it would be without &aa; protection.
> +
> +<!-- agreed. Nevertheless, you should mention Cx as another option for "less" -->
> </para>
> </listitem>
> </itemizedlist>
> <para>
> In other circumstances, you might instead want to use the
> - <guimenu>Profile</guimenu> option. This has two effects on
> + <guimenu>Profile</guimenu> option. This has three effects on
> <command>aa-logprof</command>:
> </para>
> <itemizedlist>
> <listitem>
> <para>
> - The rule written into the profile uses px, which forces the
> + The rule written into the profile uses px/Px, which forces the
> transition to the child's own profile.
> </para>
> </listitem>
> @@ -1796,6 +1840,7 @@
> by assigning events for the child process to the child's profile and
> asking the <command>aa-logprof</command> user questions.
> </para>
> +<!-- three: the profile will also be applied if you run the child as stand-alone program -->
> </listitem>
> </itemizedlist>
> <para>
> @@ -1803,6 +1848,7 @@
> <command>aa-logprof</command> sees this and asks the user which
> execution mode should be used when launching the child process. The
> execution modes of inherit, profile, unconfined or an option to deny
> +<!-- also child and named profile -->
> the execution are presented.
> </para>
> <para>
> @@ -1821,6 +1867,7 @@
> sanitize, <literal>px</literal> is placed in the profile and no
> environment sanitizing occurs. The default for the execution mode is
> <literal>px</literal> if you select profile execution mode.
> + <!-- ^^ sure? I'd guess Px -->
> </para>
> <para>
> The unconfined execution mode is not recommended and should only be
> @@ -1837,13 +1884,24 @@
> <important>
> <title>Running Unconfined</title>
> <para>
> - Choosing <literal>ux</literal> is very dangerous and provides no
> + Choosing <literal>ux or Ux</literal> is very dangerous and provides no
> enforcement of policy (from a security perspective) of the resulting
> execution behavior of the child program.
> </para>
> </important>
> </sect3>
> +
> +<!-- that all said:
> + the aa-genprof and aa-logprof section have large parts of identical content.
> + What about merging them?
> + -->
> +
> +
> <!-- not in Code 10. Will maybe be back later
> +
> +apparmor.vim is available nowadays, so please do not hide this section
> +(please also check if the color list is still correct and complete)
> +
> <sect3 id="sec.apparmor.commandline.profiling.summary.vim">
> <title>apparmor.vim</title>
>
> @@ -1865,6 +1923,10 @@
> set modeline
> set modelines=5
> </screen>
> +
> +IIRC vim comes with apparmor highlighting automatically enabled for files in /etc/apparmor.d/
> +so modlines might not be needed
> +
> <para>
> When you enable this feature, vim colors the lines of the profile for
> you:
> @@ -1875,6 +1937,7 @@
> <term>Blue</term>
> <listitem>
> <para><literal>#include</literal> lines that pull in other &aa; rules
> +I'm quite sure #include is no longer blue...
> and comments that begin with <literal>#</literal>
> </para>
> </listitem>
> @@ -1925,6 +1988,7 @@
> syntax mode presented in files you are editing. It might enable an
> attacker to send you a file to open with vim that might do
> something unsafe.
> +This paragraph should be next to the paragraph about modelines, not here
> </para>
> </note>
>
> Index: xml/apparmor_profiles_yast.xml
> ===================================================================
> --- xml/apparmor_profiles_yast.xml (Revision 11911)
> +++ xml/apparmor_profiles_yast.xml (Arbeitskopie)
> @@ -77,7 +77,9 @@
> </sect1>
> <sect1 id="sec.apparmor.yast.edit">
> <title>Editing Profiles</title>
> -
> +<!-- I know this section is about YaST, nevertheless you should mention "vi $profile" somewhere ;-)
> + (vi also includes nice syntax highlighing and syntax error highlighting)
> + -->
> <para>
> &aa; enables you to edit &aa; profiles manually by adding, editing, or
> deleting entries. To edit a profile, proceed as follows:
> @@ -435,6 +437,8 @@
> </procedure>
> </sect2>
>
> +<!-- please add a note/warning saying "You need to restart running programs to apply the profiles to them" -->
> +
> <sect2 id="sec.apparmor.yast.manage.profmodes">
> <title>Changing the Mode of Individual Profiles</title>
> <para>
> @@ -446,6 +450,7 @@
> profiles and is used by the &aa; tools for generating profiles. Loading
> a profile in <emphasis>enforce</emphasis> mode enforces the policy
> defined in the profile and reports policy violation attempts to syslogd.
> +<!-- or auditd or journalctl -->
> </para>
> <?dbfo-need height="20em"?>
> <para>
> Index: xml/apparmor_repositories.xml
> ===================================================================
> --- xml/apparmor_repositories.xml (Revision 11911)
> +++ xml/apparmor_repositories.xml (Arbeitskopie)
> @@ -11,6 +11,7 @@
> &aa; ships with a set of profiles enabled by default. These are created by
> the &aa; developers, and are stored in
> <filename>/etc/apparmor.d</filename>. In addition to these profiles,
> +<!-- AppArmor 3.0 will have them in /usr/share/ -->
> <phrase
> os="sles;sled;osuse">&productname;</phrase><phrase os="slert">&slert;</phrase>
> ships profiles for individual applications together with the relevant
> @@ -32,10 +33,10 @@
> <title>Using the Local Repository</title>
>
> <para>
> - The &aa; tools (&yast; and <command>aa-genprof</command> and
> + The &aa; tools (&yast;, <command>aa-genprof</command> and
> <command>aa-logprof</command>) support the use of a local repository.
> Whenever you start to create a new profile from scratch, and there
> - already is one inactive profile in your local repository, you are asked
> + already is an inactive profile in your local repository, you are asked
> whether you would like to use the existing inactive one from
> <filename>/etc/apparmor/profiles/extras</filename> and whether you want
> to base your efforts on it. If you decide to use this profile, it gets
> Index: xml/apparmor_start.xml
> ===================================================================
> --- xml/apparmor_start.xml (Revision 11911)
> +++ xml/apparmor_start.xml (Arbeitskopie)
> @@ -51,6 +51,7 @@
>
> <para>
> &aa; is not installed by default on &productnamereg;. Install the pattern
> +<!-- it is installed by default on openSUSE, please check for SLE -->
> <systemitem class="resource">apparmor</systemitem> for a complete &aa;
> installation. Either use the &yast; Software Management module for
> installation, or the following zypper command:
> @@ -66,6 +67,8 @@
> </para>
> -->
>
> +<!-- the intro paragraph above should be visible (please check the "installed by default" part) -
> + without it, there's just a package list without explanation -->
> <itemizedlist spacing="compact">
> <listitem>
> <para>
> @@ -114,6 +117,7 @@
>
> <para>
> &aa; is configured to run by default on any fresh installation of
> + <!-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -->
> &productname;. There are two ways of toggling the status of &aa;:
> </para>
>
> @@ -256,6 +260,7 @@
> <title>For More Information</title>
> <para>
> For more information about choosing the the right applications to
> + <!-- "the the" -->
> profile, refer to <xref linkend="sec.apparmor.concept.determine"/>.
> </para>
> </tip>
> @@ -272,6 +277,7 @@
> <para>
> There are two ways of managing profiles. One is to use the graphical
> front-end provided by the &yast; &aa; modules and the other is to use the
> + <!-- the genprof/logprof part of YaST was dropped -->
> command line tools provided by the &aa; suite itself. Both methods
> basically work the same way.
> </para>
> @@ -291,6 +297,7 @@
> <emphasis>or</emphasis>
> </para>
> <para>
> + <!-- this part of YaST is not too useful IMHO - "vi $profile" works better ;-) -->
> Outline the basic profile by running <menuchoice>
> <guimenu>&yast;</guimenu> <guimenu>Security and Users</guimenu>
> <guimenu>&aa; Configuration</guimenu> <guimenu>Manually Add
> @@ -299,6 +306,7 @@
> </para>
> <para>
> A basic profile is outlined and &aa; is put into learning mode, which
> + <!-- only the new profile is put into learning mode -->
> means that it logs any activity of the program you are executing, but
> does not yet restrict it.
> </para>
> @@ -336,6 +344,7 @@
> <step id="st.genprof4">
> <para>
> Once all access permissions are set, your profile is set to enforce
> +<!-- ^^^^^^^^^^ better: When you finish aa-genprof, your profile is set ... -->
> mode. The profile is applied and &aa; restricts the application
> according to the profile just created.
> </para>
> @@ -369,11 +378,13 @@
> </member>
> <member><filename>dmesg</filename>
> </member>
> +<!-- journalctl and systemctl status foo.service might also be interesting -->
> </simplelist>
>
> <para>
> To adjust the profile, analyze the log messages relating to this
> application again as described in <xref linkend="st.genprof3"/>.
> + <!-- better point to aa-logprof -->
> Determine the access rights or restrictions when prompted.
> </para>
>
> @@ -521,6 +532,7 @@
> and lets you adjust your profile set accordingly. Any application
> behavior that is outside of any profile definition can be addressed by
> the <command>aa-logprof</command>. For more information, see
> +<!-- ... by aa-logprof ... -->
> <xref
> linkend="sec.apparmor.commandline.profiling.summary.logprof"/>.
> </para>
> Index: xml/apparmor_support.xml
> ===================================================================
> --- xml/apparmor_support.xml (Revision 11911)
> +++ xml/apparmor_support.xml (Arbeitskopie)
> @@ -362,6 +362,7 @@
> following:
> </para>
> <screen>type=APPARMOR_DENIED msg=audit(1188913493.299:9304): operation="file_lock" requested_mask="::k" denied_mask="::k" fsuid=1000 name="/home/tux/.qt/.qtrc.lock" pid=25736 profile="/usr/bin/opera"
> +<!-- looks like the old log format -->
> </screen>
> <para>
> Update the profile using the <command>aa-logprof</command> command as
> @@ -378,6 +379,7 @@
> </para>
> <screen>
> type=APPARMOR_DENIED msg=audit(1188894313.206:9123): operation="socket_create" family="inet" sock_type="raw" protocol=1 pid=23810 profile="/bin/ping"
> +<!-- looks like the old log format -->
> </screen>
> <para>
> This log entry means that our example application,
> @@ -440,6 +442,7 @@
> The following rule works similarly both under the old and the new
> syntax, and allows access to both files and directories under
> <filename>/proc/net</filename>:
> +<!-- (but does not allow a directory listing of /proc/net/ itsself) -->
> </para>
> <screen>
> /proc/net/** r,
> @@ -522,6 +525,7 @@
>
> <sect2 id="sec.apparmor.support.trouble.kde">
> <title>How to Confine KDE Applications with &aa;?</title>
> +<!-- did you ask a KDE developer if this is still valid? -->
> <para>
> Currently, it is not possible to confine KDE applications to the same
> extent as any other application, due to the way KDE manages its
> @@ -544,6 +548,7 @@
> (kiosk-type) one. Maintaining such a profile for a standard KDE
> desktop (including all of its applications) would be close to
> impossible.
> +<!-- or superfluous because it would need to allow *a lot* -->
> </para>
> </listitem>
> </varlistentry>
> @@ -552,7 +557,7 @@
> <listitem>
> <para>
> Using <literal>KDE_EXEC_SLAVES=1</literal> and
> - <literal>KDE_IS_PRELINKED=1</literal> variables force KDE to manage
> + <literal>KDE_IS_PRELINKED=1</literal> variables forces KDE to manage
> its processes in a way that allows &aa; to distinguish individual
> applications from each other and apply profiles to them. This
> approach might slow down your desktop considerably, as it turns off a
> @@ -605,6 +610,7 @@
> command creates a symbolic link to the profile in
> <filename>/etc/apparmor.d/disable/</filename>. In order to reactivate
> the profile, just delete that link.
> +<!-- and run rcapparmor reload -->
> </para>
> </sect2>
>
> @@ -613,7 +619,7 @@
> <para>
> Managing profiles with &aa; requires you to have access to the log of
> the system on which the application is running. So you do not need to
> - run the application on your profile, build host as long as you have
> + run the application on your profile build host as long as you have
> access to the machine that runs the application. You can run the
> application on one system, transfer the logs
> (<filename>/var/log/audit.log</filename> or, if
> Index: xml/apparmor_whatimmunize.xml
> ===================================================================
> --- xml/apparmor_whatimmunize.xml (Revision 11911)
> +++ xml/apparmor_whatimmunize.xml (Arbeitskopie)
> @@ -218,7 +218,8 @@
> <para>
> <command>aa-logprof</command> interactively scans and reviews the log
> entries generated by an application that is confined by an &aa;
> - profile in complain mode. It assists you in generating new entries in
> + profile. It assists you in generating new entries in
> +<!-- not only complain mode, also profiles in enforce mode -->
> the profile concerned. Refer to
> <xref linkend="sec.apparmor.commandline.profiling.summary.logprof"/>
> for detailed information about this tool.
> @@ -235,7 +236,7 @@
> use of templates and policy groups to quickly profile an application.
> Please note that while this tool can help with policy generation, its
> utility is dependent on the quality of the templates, policy groups
> - and abstractions used. <command>aa-easyprof</command> may create
> + and abstractions used. <command>aa-easyprof</command> may create a
> profile which is less restricted than creating the profile with
> <command>aa-genprof</command> and <command>aa-logprof</command>.
> </para>
> @@ -303,7 +304,8 @@
> Once a profile has been built and is loaded, there are two ways in which
> it can get processed:
> </para>
> -
> +<!-- the following paragraphs about aa-complain and aa-enforce basically repeat what was said above.
> + I'd remove or merge them -->
> <variablelist>
> <varlistentry>
> <term><command>aa-complain</command>
> @@ -394,6 +396,7 @@
> instance, a shell script might invoke the <command>cp</command> program
> to copy a file. Because <command>cp</command> does not have its own
> profile, it inherits the profile of the parent shell script, so can copy
> + <!-- well, in theory cp could have an own profile or subprofile -->
> any files that the parent shell script's profile can read and write.
> </para>
> </sect1>
> @@ -419,6 +422,7 @@
> For &rootuser;'s cron jobs, edit the tasks with <command>crontab
> -e</command> and list &rootuser;'s cron tasks with <command>crontab
> -l</command>. You must be &rootuser; for these to work.
> + <!-- wrong/misleading - "crontab" lists/edits the current user's crontab -->
> </para>
> </sect1>
> <sect1 id="sec.apparmor.concept.network">
> @@ -528,7 +532,7 @@
> <para>
> To aggressively confine desktop applications, the
> <command>aa-unconfined</command> command supports a
> - <option>paranoid</option> option, which reports all processes running and
> + <option>--paranoid</option> option, which reports all processes running and
> the corresponding &aa; profiles that might or might not be associated
> with each process. The user can then decide whether each of these
> programs needs an &aa; profile.
> @@ -538,6 +542,7 @@
> If you have new or modified profiles, you can submit them to the
> <ulink
> url="mailto:apparmor-general at forge.novell.com">apparmor-general at forge.novell.com</ulink>
> + <!-- outdated ML address - you know the current one ;-) -->
> mailing list along with a use case for the application behavior that you
> exercised. The &aa; team reviews and may submit the work into
> <phrase os="sles;sled;osuse">&productname;</phrase><phrase
> @@ -550,6 +555,7 @@
> </para>
>
> <para os="sles;osuse;sled">
> + <!-- the profile repo is gone, so should this paragraph -->
> Alternatively, use the &aa; profile repository to make your profiles
> available to other users and to download profiles created by other &aa;
> users and the &aa; developers. Refer to
> @@ -586,7 +592,8 @@
> >&productname;</phrase><phrase os="slert">&slert;</phrase>,
> must be modified to add execute permissions to each of these programs.
> For instance, adding the line
> - <literal>/srv/www/cgi-bin/my_hit_counter.pl rpx</literal> grants Apache
> + <literal>/srv/www/cgi-bin/my_hit_counter.pl rPx</literal> grants Apache
> + <!-- uppercase Px sounds like a better example -->
> permission to execute the Perl script
> <filename>my_hit_counter.pl</filename> and requires that there be a
> dedicated profile for <filename>my_hit_counter.pl</filename>. If
> @@ -680,12 +687,14 @@
> /srv/www/vhosts r,
> /srv/www/vhosts/** r,
> /usr/share/apache2/** r,
> - /var/lib/php/sess_* rwl }
> + /var/lib/php/sess_* rwl
> +}
> </screen>
> <para>
> To use a single &aa; profile for all Web pages and CGI scripts served by
> Apache, a good approach is to edit the
> <systemitem>DEFAULT_URI</systemitem> subprofile.
> + <!-- add "see also" pointing to mod_apparmor configuration -->
> </para>
> </sect2>
>
> Index: xml/security_docupdates.xml
> ===================================================================
> --- xml/security_docupdates.xml (Revision 11911)
> +++ xml/security_docupdates.xml (Arbeitskopie)
> @@ -109,7 +109,8 @@
> <itemizedlist>
> <listitem>
> <para>
> - New <literal>Pux/pux</literal> and <literal>Cux/cux</literal>
> + New <literal>PUx/pux</literal> and <literal>Cux/cux</literal>
> +<!-- Pux (mixed upper-/lowercase) will fail parsing -->
> profile transitions added in
> <xref linkend="sec.apparmor.profiles.exec.fallback"/>.
> </para>
>
>
>
> -- AppArmor mailing list AppArmor at lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
>
More information about the AppArmor
mailing list