MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1048
made it so rules like
mount slave /snap/bin/** -> /**,
mount /snap/bin/** -> /**,
would get passed into change_mount_type rule generation when they
shouldn't have been. This would result in two different errors.
1. If kernel mount flags were present on the rule. The error would
be caught causing an error to be returned, causing profile compilation
to fail.
2. If the rule did not contain explicit flags then rule would generate
change_mount_type permissions based on souly the mount point. And
the implied set of flags. However this is incorrect as it should
not generate change_mount permissions for this type of rule. Not
only does it ignore the source/device type condition but it
generates permissions that were never intended.
When used in combination with a deny prefix this overly broad
rule can result in almost all mount rules being denied, as the
denial takes priority over the allow mount rules.
Fixes: https://bugs.launchpad.net/apparmor/+bug/2023814
Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1211989
Fixes: 9d3f8c6cc ("parser: fix parsing of source as mount point for propagation type flags")
Fixes: MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1048
Signed-off-by: John Johansen <john.johansen@canonical.com>
Before 300889c3a, mount rules would compile policy when using source
as mount point for rules that contain propagation type flags, such as
unbindable, runbindable, private, rprivate, slave, rslave, shared, and
rshared. Even though it compiled, the rule generated would not work as
expected.
This commit fixes both issues. It allows the usage of source as mount
point for the specified flags, albeit with a deprecation warning, and
it correctly generates the mount rule.
The policy fails to load when both source and mount point are
specified, keeping the original behavior (reference
parser/tst/simple_tests/mount/bad_opt_10.sd for example).
Fixes: https://bugs.launchpad.net/bugs/1648245
Fixes: https://bugs.launchpad.net/bugs/2023025
It should be backported to versions 2.13, 3.0, 3.1.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1048
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit 1e0d7bcbb7)
Signed-off-by: John Johansen <john.johansen@canonical.com>
This patch adds the following mount options: 'nostrictatime',
'lazytime', and 'nolazytime'.
The MS_STRICTATIME mount flag already existed, and 'nostrictatime' was
listed along with 'strictatime' in the comments of parser/mount.cc, so
this patch adds a mapping for 'nostrictatime' to clear MS_STRICTATIME.
Additionally, the Linux kernel includes the 'lazytime' option with
MS_LAZYTIME mapping to (1<<25), so this patch adds MS_LAZYTIME to
parser/mount.h and the corresponding mappings in parser/mount.cc for
'lazytime' and 'nolazytime'.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1005
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit c37be61d17)
Signed-off-by: Jon Tourville <jon.tourville@canonical.com>
This is a partial fix for CVE-2016-1585, it address the frontend rule encoding problems particularly
- Permissions being given that shouldn't happen
- Multiple option conditionals in a single rule resulting in wider permission instead of multiple rules
- optional flags not being handled correctly
- multiple backend rules being created out of one frontend rule when they shouldn't be
it does not address the backend issue of short cut permissions not being correctly updated when deny rules carve out permissions on an allow rule that has a short cut permission in the encoding.
Thanks to the additional work by Alexander Mikhalitsyn for beating this MR into shape so we can land it
Alexander Changelog:
- rebased to an actual tree
- addressed review comments from @wbumiller and @setharnold
- fixed compiler warnings about class_mount_hdr is uninitialized
- infinite loop fix
- MS_MAKE_CMDS bitmask value fixed
- fixed condition in `gen_flag_rules` to cover cases like `mount options in (bind) /d -> /4,` when flags are empty and only opt_flags are present
- marked some tests as a FAIL case behavior was changed after `parser: add conflicting flags check for options= conditionals` commit
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/333
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit c1a1a3a923)
Signed-off-by: John Johansen <john.johansen@canonical.com>
by adding a warning flag that is disabled by default. This will enable
devs to find when and where #include is in use by adding the compile
flag
--warn=pound-include
and can even abort policy compiles by using
--warn=pound-include --Werror=pound-include
The resulting messages look like
Warning from /etc/apparmor.d/usr.sbin.cupsd (/etc/apparmor.d/usr.sbin.cupsd line 5): deprecated use of '#include'
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Time-out
I've seen this test fail because "apparmor_parser -N" returned the expected
lines, but in a different order than what's expected (dirtest.out).
To fix this, sort both the expected and actual output.
Per the discussion in #243, this MR removes Python 2 compatibility. Namely, this merge request:
- removes code behind `sys` and `platform` interpreter version checks
- removes `unicode` vs. `str` handling
- removes unnecessary `__future__` imports
- removes unnecessary `object` inheritance
- removes unnecessary `super()` arguments
- uncomments commented-out code with "uncomment when python3 only" notes or some variant of that message
Regarding the `unicode` vs. `str` handling, it's arguably more Pythonic to check `isinstance(x, str)` as opposed to `type(x) is str`, but I didn't want to alter code behavior.
A change needs to be made to the `INCOMPLETE_COVERAGE` setting in `utils/test/Makefile` to get the pipeline to pass. I didn't get anywhere tweaking the setting myself, so someone else with more AppArmor experience will have to make that change.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/894
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
This is a follow-up on !812, which added a call to systemd-detect-virt.
Everywhere else we don't assume that program is present,
and first check if it's there before we run it.
Let's do the same here.
The inverse character set lists the characters it doesn't match. If
the inverse character set contains an oob then that is NOT considered
a match. So length should be one.
However because of oobs are handle not containing an oob doesn't mean
there is a match either. Currently the only way to match an oob is
via a positive express (no inverse matches are possible).
Signed-off-by: John Johansen <john.johansen@canonical.com>
Without the change apparmor build fails on this week's gcc-13 snapshot as:
capability.h:66:6: error: variable or field '__debug_capabilities' declared void
66 | void __debug_capabilities(uint64_t capset, const char *name);
| ^~~~~~~~~~~~~~~~~~~~
capability.h:66:27: error: 'uint64_t' was not declared in this scope
66 | void __debug_capabilities(uint64_t capset, const char *name);
| ^~~~~~~~
capability.h:23:1: note: 'uint64_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
22 | #include <linux/capability.h>
+++ |+#include <cstdint>
23 |
... if a test is expected to fail, but succeeds.
Also fix the copyright year - the test was created in 2022, not in 2013.
This fixes my comments on
bd78b6b292
libapparmor: fix handling of failed symlink traversal, fixed a couple
of directory walk issues that could cause failures. The test included
in this commit was supposed to be included in the previous commit,
but was accidentally dropped. Even worse the make file changes did
make it causing the previous commit to break the CI.
Fixes: MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/85
Signed-off-by: John Johansen <john.johansen@canonical.com>
As shellcheck taught me
today (https://github.com/koalaman/shellcheck/wiki/SC2015),
"A && B || C is not if-then-else. C may run when A is true".
It does not matter here in practice, because worst case we would run "true" once
too many, but still.
In this case it does not matter, we're merely testing if we can actually
read from that file, but let's make this robust (and shellcheck happy)
for future's sake.
Reference: https://www.shellcheck.net/wiki/SC2162
In 73e124d4fb I've upstreamed the `is_container_with_internal_policy()` function, but so far it was not used anywhere upstream. This is the missing bit.
I could trace the history of that patch back to 2012 (2.7.102-0ubuntu3):
* debian/apparmor.init: do nothing in a container. This can be
removed once stacked profiles are supported and used by lxc.
(LP: #978297)
Context: I lack both knowledge and motivation to keep maintaining this as part of the Debian delta. I'd rather see upstream, and in particular folks more knowledgeable than me about LXC/LXD, or with external motivation factors to work on this part of the stack, take care of it.
Note: Debian has similar code in its [sysvinit script](https://salsa.debian.org/apparmor-team/apparmor/-/blob/debian/master/debian/apparmor.init). I'm not touching that one.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/840
Acked-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
