These applications need to use user namespaces, hence it needs an
unconfined profile when user namespaces are restricted from unconfined
like other applications in MR #1123https://gitlab.com/apparmor/apparmor/-/merge_requests/1123
In addition this serves as a handle to uniquely identify them instead
of unconfined to peers in policy.
Bug: https://bugs.launchpad.net/bugs/2046844
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Latest pam_unix always runs /usr/sbin/unix_chkpwd instead of reading
/etc/shadow itsself. Add exec permissions to abstraction/authentication.
It also needs to read /proc/@{pid}/loginuid
Also cleanup the now-superfluous rules from the smbd profile.
Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1219139
With abstractions/openssl now being included from abstraction/base
(via the indirection of abstractions/crypto) anything already
including abstraction/base can stop including abstractions/openssl
directly.
Administrators might want to define global limits (e.g. disabling
a particular feature) via configuration files, but to make that work
all confined software needs to be allowed to read those files or
otherwise the risk is to silently fall back to internal defaults.
This adds the abstraction already defined for openssl to
abstraction/crypto as it is about cryptography, but also because
abstraction/base includes abstraction/crypto and therefore it will
be allowed in general.
Administrators might want to define global limits (e.g. disabling
a particular feature) via configuration files, but to make that work
all confined software needs to be allowed to read those files or
otherwise the risk is to silently fall back to internal defaults.
This adds the paths usually used by gnutls to abstraction/crypto
as it is about cryptography, but also because abstraction/base
includes abstraction/crypto and therefore it will be allowed
in general.
Nautilus uses user namespaces to load thumbnails, hence it needs an
unconfined profile when user namespaces are restricted from unconfined
like other applications in MR #1123
Although nautilus has extensions that would allow opening a terminal
from the nautilus interface, they do not inherit nautilus' AppArmor
label, therefore the use of unconfined does not allow arbitrary use of
unprivileged user namespaces using the nautilus label.
https://gitlab.com/apparmor/apparmor/-/merge_requests/1123
In addition this serves as a handle to uniquely identify them instead
of unconfined to peers in policy.
Note that unconfined mode should be changed for default_allow when
https://gitlab.com/apparmor/apparmor/-/merge_requests/1109 is merged.
Fixes: https://bugs.launchpad.net/bugs/2047256
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
The current attachment works from the commandline but not from
gnome as it uses an alternate path.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/368
Signed-off-by: John Johansen <john.johansen@canonical.com>
Some openssl distributions use version specific engdef and engines paths
to support multi-version installations.
Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1219571
Signed-off-by: David Disseldorp <ddiss@suse.de>
These applications need to use user namespaces, hence it needs an
unconfined profile when user namespaces are restricted from unconfined
like other applications in MR #1123https://gitlab.com/apparmor/apparmor/-/merge_requests/1123
In addition this serves as a handle to uniquely identify them instead
of unconfined to peers in policy.
Note that unconfined mode should be changed for default_allow when
https://gitlab.com/apparmor/apparmor/-/merge_requests/1109 is merged.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Keybase needs to use user namespaces, hence it needs an unconfined
profile when user namespaces are restricted from unconfined like other
applications in MR #1123https://gitlab.com/apparmor/apparmor/-/merge_requests/1123
In addition this serves as a handle to uniquely identify keybase
instead of unconfined to peers in policy.
Note that unconfined mode should be changed for default_allow when
https://gitlab.com/apparmor/apparmor/-/merge_requests/1109 is merged.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Unprivileged user namespace creation is allowed an will result in a
transition into the unprivileged_userns profile. The
unprivileged_userns profile with then deny all capabilities within the
profile. Execution of applications is allowed within the
unprivileged_userns profile but, they will result in a stack with the
unprivileged_userns profile, that is to say the unprivileged_userns
profile can not be dropped (capabilities can not be gained).
If the unprivileged_userns profile does not exist, unprivileged user
namespace creation is denied as before.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
These are profiles for applications that create user namespaces, both
the actual policy and unconfined profiles, like it was done in MR
1123.
https://gitlab.com/apparmor/apparmor/-/merge_requests/1123
In addition this serves as a handle to uniquely identify these
applications instead of unconfined to peers in policy.
Note that unconfined mode should be changed for default_allow when
https://gitlab.com/apparmor/apparmor/-/merge_requests/1109 is merged.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
The recently added unconfined profiles use the binary name for the
local include instead of the profile name. Switch to using the
profile name for the local include.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Steam needs to use user namespaces, hence it needs an unconfined
profile when user namespaces are restricted from unconfined like other
applications in MR1123
https://gitlab.com/apparmor/apparmor/-/merge_requests/1123
In addition this serves as a handle to uniquely identify stream
instead of unconfined to peers in policy.
Note that unconfined mode should be changed for default_allow
when https://gitlab.com/apparmor/apparmor/-/merge_requests/1109 is
merged.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Adding profiles for applications even if they allow all operations
will allow them to be referenced as peer by other policies. This is a
step towards a more comprehensive system policy, adding names, instead
of just unconfined, to peers of existing policy and to applications
that are known to use unprivileged user namespaces.
Note that unconfined mode should be changed for default_allow
when https://gitlab.com/apparmor/apparmor/-/merge_requests/1109 is
merged.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Out of the box the KDE plasma-browser-integration package does not work
after a user installed the corresponding Firefox extension: The browser
can't start the native host binary. The same is probably true for
Chromium.
This was originally reported to KDE at https://bugs.kde.org/show_bug.cgi?id=397399
Though many Linux distros choose to pass _/usr/lib_ as the libexecdir while configuring dovecot, such as [Debian](https://sources.debian.org/src/dovecot/1%3A2.3.20%2Bdfsg1-1/debian/rules/#L132) and [Arch](https://gitlab.archlinux.org/archlinux/packaging/packages/dovecot/-/blob/main/PKGBUILD#L76), others like Alpine Linux and Gentoo don't pass anything as libexecdir, allowing it to default to _/usr/libexec_.
Both appear to be valid. From [FHS 3.0, Chapter 4.7](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html):
> Some previous versions of this document did not support _/usr/libexec_, despite it being standard practice in a number of environments. To accomodate this restriction, it became common practice to use _/usr/lib_ instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself.
Allow for the default libexec subdir _/usr/libexec/dovecot_ as well as the more common
_/usr/lib/dovecot_.
Signed-off-by: Peter Levine <plevine457@gmail.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1080
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
(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.
Also extend make check to ensure that all tunables include tunables/$FILE.d
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/347
I propose this patch for 3.0..master.
Closes#347
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1077
Approved-by: timeout
Merged-by: Christian Boltz <apparmor@cboltz.de>
Allow for the default libexec subdir, /usr/libexec/dovecot, as well
as the more common /usr/lib/dovecot.
Signed-off-by: Peter Levine <plevine457@gmail.com>
(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
Begin preparing policy for the 4.0 release. This may result in new
denials. This is expected and needed to make sure policy is ready
for the 4.0 release.
Signed-off-by: John Johansen <john.johansen@canonical.com>
I have a number of updates for the Firefox profile, based on monitoring AppArmor logs in the course of my own usage.
I'm going to try annotating the diff with the appropriate log messages, to see if that is a useful way of documenting the changes.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1055
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
Found in testing a slimmed-down `usr.sbin.sshd` profile:
```
Jun 8 21:09:38 testvm kernel: [ 54.847014] audit: type=1400 audit(1686272978.009:68): apparmor="DENIED" operation="open" profile="/usr/sbin/sshd" name="/sys/kernel/mm/transparent_hugepage/hpage_pmd_size" pid=1035 comm="sshd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
```
Not sure what glibc/system call uses this, but it seems pretty broadly applicable, and read access is presumably harmless. [THP reference](https://www.kernel.org/doc/html/latest/admin-guide/mm/transhuge.html)
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1050
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
/etc/ld-musl-*.path is required to perform dynamic linking on musl libc.
The wildcard is to match all CPU architectures, like x86_64.
type=AVC msg=audit(1686087677.497:67): apparmor="DENIED" operation="open" class="file" profile="syslog-ng" name="/etc/ld-musl-x86_64.path" pid=25866 comm="syslog-ng" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Closes#333
Signed-off-by: Nikita Romaniuk <kelvium@yahoo.com>
Closes#333
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1047
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
This brings in numerous improvements from the Firefox AppArmor profile that Ubuntu ships in 20.04/focal. The raw profile may be viewed [here](https://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/view/head:/debian/usr.bin.firefox.apparmor.14.10) (or alternately [here](https://bazaar.launchpad.net/~mozillateam/firefox/firefox.focal/view/head:/debian/usr.bin.firefox.apparmor.14.10)).
To review, you may not only want to compare this new version against HEAD, but also against the Ubuntu profile, which has a smaller diff. I suggest preprocessing the latter with the following to reduce extraneous diffs:
```
sed 's,@{PROC}/\[0-9\]\*/,@{PROC}/@{pid}/,g; s,/@{pid}/task/\[0-9\]\*/,/@{pid}/task/@{tid}/,g; s/#\(include\)/\1/'
```
I've made a few minor edits along the way, such as using AppArmor variables instead of preprocessing directives (like `@MOZ_LIBDIR@`) that are substituted in the Firefox package build. Any feature/stylistic downgrades in the Ubuntu profile should have been filtered out.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1043
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
/etc/ld-musl-*.path is required to perform dynamic linking on musl libc.
The wildcard is to match all CPU architectures, like x86_64.
type=AVC msg=audit(1686087677.497:67): apparmor="DENIED" operation="open" class="file" profile="syslog-ng" name="/etc/ld-musl-x86_64.path" pid=25866 comm="syslog-ng" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Closes#333
Signed-off-by: Nikita Romaniuk <kelvium@yahoo.com>
