(except the deprecated tunables/sys)
This allows users to extend variables without editing the main tunables
files.
It also allows to cleanly introduce new tunable files (via
tunables/global.d) and new aliases (via tunables/alias.d).
Note: some files already had `include <tunables/$FILE.d>`. These get
changed to `include if exists`, and the comments for these includes get
unified.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/347
The description of @{etc_ro} and @{etc_rw} were not good enough in
explaining which directories they should contain, and when to use which
of the variables in a profile.
Move @{sys} into tunables/kernelvars to make it readily available for
all profiles by default. In order to avoid duplicate variable
declaration, other tunable includes where modified accordingly.
Additionally, apparmor_api/is_enable has updated comment with regards to
@{sys} availability. tunables/sys is now marked as deprecated and should
not be used as it is noop, left only for backwards compatibility.
This is preparation for fixing bug:
https://bugs.launchpad.net/apparmor/+bug/1728551
Thanks to Christian Boltz for original idea to implement this in
non-breaking manner.
Add @{uid} and @{uids} variables to allow migrating profiles in advance
while awaiting path mediation implementation, based on current user id,
in kernel side.
As Simon McVittie <smcv@collabora.com> wrote on
https://bugs.debian.org/865206 and on the AppArmor mailing list:
"Anything in /var/lib/flatpak/exports/share or
~/.local/share/flatpak/exports/share is essentially equivalent to
the corresponding path in /usr/{local/,}share, and is something
that has deliberately been "exported" to the rest of the system by a
Flatpak-confined app.
The only reason to prevent reading those directories would be if you do
not want the AppArmor-confined app to be able to enumerate the other
software you have installed on your system, as an anti-fingerprinting
mechanism.".
Bug-Debian: https://bugs.debian.org/865206
The xdg-user-dirs specification[1] allows for translatable and movable common
directories. While this may be beneficial for users who for example want to have
~/Pictures translated into their own language, this flexibility provides
challenges for AppArmor. Untranslated xdg user directories are typically (see
~/.config/user-dirs.dirs):
XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/Music"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_VIDEOS_DIR="$HOME/Videos"
On an Ubuntu system with the fr_CA locale installed, these become:
XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOWNLOAD_DIR="$HOME/Téléchargements"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_MUSIC_DIR="$HOME/Musique"
XDG_PICTURES_DIR="$HOME/Images"
XDG_VIDEOS_DIR="$HOME/Vidéos"
While the kernel and AppArmor parser handle these translations fine, the
profiles do not.
As an upstream, we can vastly improve the situation by simply creating the
xdg-user-dirs tunable using the default 'C' xdg-user-dirs values:
$ cat /etc/apparmor.d/tunables/xdg-user-dirs
@{XDG_DESKTOP_DIR}=Desktop
@{XDG_DOWNLOAD_DIR}=Downloads
@{XDG_TEMPLATES_DIR}=Templates
@{XDG_PUBLICSHARE_DIR}=Public
@{XDG_DOCUMENTS_DIR}=Documents
@{XDG_MUSIC_DIR}=Music
@{XDG_PICTURES_DIR}=Pictures
@{XDG_VIDEOS_DIR}=Videos
# Also, include files in tunables/xdg-user-dirs.d for site-specific adjustments
# to the various XDG directories
#include <tunables/xdg-user-dirs.d>
and then create the /etc/apparmor.d/tunables/xdg-user-dirs.d directory. With
that alone, we can start using rules like this in policy:
owner @{HOME}/@{XDG_MUSIC_DIR}/** r,
and users/admins can adjust /etc/apparmor.d/tunables/xdg-user-dirs or drop files
into /etc/apparmor.d/tunables/xdg-user-dirs.d, providing a welcome convenience.
This of course doesn't solve everything. Because users can modify their
~/.config/user-dirs.dirs file at will and have it point anywhere, so we can't
examine those files and do anything automatic there (when we have user policy we
can revisit this). This patch handles translations well though since use of
translations for these directories happens outside of the user's control. Users
who modify ~/.config/user-dirs.dirs can update policy like they need to now (ie,
this patch doesn't change anything for them).
[0] https://lists.ubuntu.com/archives/apparmor/2013-August/004183.html
[1] http://freedesktop.org/wiki/Software/xdg-user-dirs/
This patch adds basic support for XDG user dirs:
1. Update profiles/apparmor.d/tunables/global to include xdg-user-dirs.
2. Create the xdg-user-dirs tunable using the default 'C' xdg-user-dirs values
and includes tunables/xdg-user-dirs.d
3. Add profiles/apparmor.d/tunables/xdg-user-dirs.d/site.local with commented
out examples on how to use the directory.
Acked-By: Jamie Strandboge <jamie@canonical.com>
Acked-By: Christian Boltz <apparmor@cboltz.de>
Introduces tunables/dovecot (with @{DOVECOT_MAILSTORE}) and replace
the mail storage location in various dovecot-related profiles with
this variable.
Also add nice copyright headers (I hope I got the bzr log right ;-)
Acked-by: John Johansen <john.johansen@canonical.com>
This patch adds the kernelvars tunable to the global set that is usually
included by default in apparmor policies. It then converts the rules
that are intended to match /proc/pid to use this tunable.
Signed-off-by: Steve Beattie <sbeattie@ubuntu.com>
Acked-By: Seth Arnold <seth.arnold@canonical.com>
The apparmor_api abstractions make the mistake of including tunables
directly, which is a no-no since the variable definitions in tunables
need to occur in the preamble of a profile, not embedded within it.
This patch removes those includes, and replaces them documentation of
tunables are necessary, as some of the expected ones are not part of
tunables/global.
It also adjust the kernelvars tunable's definition of the @{pid}
regex, as the current parser does not support nesting of {} groupings,
which breaks any profile that attempts to use the tunable.
Signed-off-by: Steve Beattie <sbeattie@ubuntu.com>
Acked-By: Seth Arnold <seth.arnold@canonical.com>
Steve Langasek <steve.langasek@linaro.org>,
Steve Beattie <sbeattie@ubuntu.com>
Description: add multiarch support to abstractions
Bug-Ubuntu: https://bugs.launchpad.net/bugs/736870
This patch add multiarch support for common shared library locations, as
well as a tunables file and directory to ease adding addiotional
multiarch paths.
Bug: https://launchpad.net/bugs/736870
tunables/proc and modifies all users of /proc to use the variable instead.
I also converted some uses of /proc/*/ to /proc/[0-9]*/ to be a
little more restrictive, as well as removing some references to proc
files that are already covered by abstractions/base (the removals in
abstractions/bash seem justified as all uses of abstractions/bash are
immediately preceded by abstractions/base).
make the final install layout match the layout in the repository (at
long last :) -- now we can use a single 'make check' target to check the
profiles in the repository against both apparmor_parser and logprof.
