/proc/$pid/cmdline can be changed by an application, therefore escape it
before printing.
The program name in /proc/$pid/exe can also contain any characters
(except \0 and shashes) and needs escaping.
Note: repr() wraps the string into single quotes, which we have to
remove to avoid changing the output format.
The test program from issue 364 now gets displayed as
28443 /path/to/issue364 (/\x1b]0;X\x07) not confined
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/364
I propose this patch for 2.13..master
Closes#364
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1142
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit e63c1e3a76)
Signed-off-by: John Johansen <john.johansen@canonical.com>
Given the following profile:
profile foo {
profile bar {
profile baz {
}
}
}
The parser would correctly serialize the "foo" profile and the
"foo//bar" profile, but it would incorrectly name "bar//baz" when it
should be "foo//bar//baz". This would cause issues loading the profile
in certain kernels causing a "parent does not exist" error.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1127
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit eb6fa02251)
Signed-off-by: John Johansen <john.johansen@canonical.com>
The variable @{etc_ro} was cherry-picked from a commit from a later
apparmor version, but it is not available on 2.13. Therefore it should
be replaced by the actual string.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
upstream kernels only have network_v8 unfortunately the tcp tests were
only being run against kernels that had network (which is v7). Kernels
that support both (Ubuntu) would be tested against v8, so v8 has been
tested but pure upstream kernels were failing to be tested correctly.
This patch will only make sure one of the supported verserions are
tested. This is determined by the parser which prefers v8. In the
future the tests need to be extended to run the tests against all
kernel supported versions.
Signed-off-by: John Johansen <john.johansen@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1120
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit dcc719c69c)
Signed-off-by: John Johansen <john.johansen@canonical.com>
Mount has regressed in two ways. That are affecting snapd confinement,
since landing the mount fixes for CVE-2016-1585 in 3.1.4 and the fix
for the mount change type regression in 3.1.5
Bug Reports:
https://bugs.launchpad.net/apparmor/+bug/2023814https://bugzilla.opensuse.org/show_bug.cgi?id=1211989
Issue 1: Denial of Mount
```
[ 808.531909] audit: type=1400 audit(1686759578.010:158): apparmor="DENIED" operation="mount" class="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.test-snapd-lp-1803535" name="/tmp/.snap/etc/" pid=14529 comm="5" srcname="/etc/" flags="rw, rbind"
```
when the profile contains a rule that should match
```
mount options=(rw, rbind) "/etc/" -> "/tmp/.snap/etc/",
```
Issue 2: change_type failure.
Denial of Mount in log
```
type=AVC msg=audit(1686977968.399:763): apparmor="DENIED" operation="mount" class="mount" info="failed flags match" error=-13 profile="snap-update-ns.authy" name="/var/cache/fontconfig/" pid=26702 comm="5" srcname="/var/lib/snapd/hostfs/var/cache/fontconfig/" flags="rw, bind"
...
```
snapd error
```
- Run configure hook of "chromium" snap if present (run hook "configure":
-----
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/share/doc /usr/share/doc none bind,ro 0 0): permission denied
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/share/fonts /usr/share/fonts none bind,ro 0 0): permission denied
update.go:85: cannot change mount namespace according to change mount (/var/snap/cups/common/run /var/cups none bind,rw 0 0): permission denied
cannot update snap namespace: cannot create writable mimic over "/snap/chromium/2475": permission denied
snap-update-ns failed with code 1
```
and NO mount rules in the profiles.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1054
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
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>
(cherry picked from commit 86d193e183)
Signed-off-by: John Johansen <john.johansen@canonical.com>
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>
(cherry picked from commit ad3750058d)
Signed-off-by: John Johansen <john.johansen@canonical.com>
/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>
(cherry picked from commit 6e0d776f65)
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>
When opening snap browsers with evince using the snap_browsers
abstraction, we get the following AppArmor denials which prevent the
browsers from opening
audit: type=1400 audit(1685996894.479:225): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/evince//snap_browsers" name="/var/lib/snapd/inhibit/firefox.lock" pid=13282 comm="snap" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1685997517.142:259): apparmor="DENIED" operation="file_lock" class="file" profile="/usr/bin/evince//snap_browsers" name="/var/lib/snapd/inhibit/firefox.lock" pid=14200 comm="snap" requested_mask="k" denied_mask="k" fsuid=1000 ouid=0
This MR should be cherry-picked into 2.13, 3.0, 3.1
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1045
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
(cherry picked from commit a00ece5b6e)
daec4bc8 profiles: add lock file permission to snap browsers
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>
The conflicting flags value message was hard to read
conflicting flag value = lazytimenolazytime
change it to
conflicting flag values = lazytime, nolazytime
Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit 89bc617d0d)
Signed-off-by: Jon Tourville <jon.tourville@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'.
Signed-off-by: Oliver Calder <oliver.calder@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit bc64b824fa)
Signed-off-by: Jon Tourville <jon.tourville@canonical.com>
The mount options MS_LAZYTIME and MS_NOSYMFOLLOW were added in
kernels 4.0 and 5.10, respectively. Update the mount test script
and helper to skip testing those options if they are not available.
Signed-off-by: Jon Tourville <jon.tourville@canonical.com>
(cherry picked from commit 9a760def8d)
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: Jon Tourville <jon.tourville@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1029
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Jon Tourville <jon.tourville@canonical.com>
`unscd` is a drop-in replacement for `nscd` that uses the same binary location (`/usr/sbin/nscd`) and config file (`/etc/nscd.conf`). The `usr.sbin.nscd` profile only needs one additional permission to support it.
```
May 9 18:07:42 darkstar kernel: [ 2706.138823] audit: type=1400
audit(1683670062.580:839): apparmor="DENIED" operation="sendmsg"
profile="nscd" name="/run/systemd/notify" pid=4343 comm="nscd"
requested_mask="w" denied_mask="w" fsuid=125 ouid=0
```
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1031
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
(cherry picked from commit dec3815f07)
bd0d401b nscd: add permission to allow supporting unscd
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: Jon Tourville <jon.tourville@canonical.com>
gen_flag_rules has a boolean vs bit and case where parenthesis are
helpful to express the intended order of operations.
It also doesn't handle the case where there are no matches. Fix this
by causing that case to fail.
also improve the debug of option extraction.
Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit f09676f5f9)
Signed-off-by: Jon Tourville <jon.tourville@canonical.com>
Now that flag processing for mount rules with single option
conditionals are fixed e-enable multiple mount conditionals on a
single mount rule. The mount conditionals are equivalent to specifying
multiple rules.
mount options=(a,b,c) options=(c,d),
is the same as
mount options=(a,b,c),
mount options=(c,d),
and
mount options in (a,b,c) options in (c,d),
is the same as
mount options in (a,b,c),
mount options in (c,d),
when multiple options= and options in are combined in a single rule
it is the same as the cross product of the options.
where
mount options=(a,b,c) options in (d,e),
is a single rule.
mount options=(a,b,c) options=(d,e) options in (f),
is equivalent to
mount options=(a,b,c) options in (f),
mount options=(d,e) options in (f),
and while it is not recommended that multiple options= and options in
conditions be used in a single rule.
mount options=(a,b,c) options=(d,e) options in (f) options in (g),
is equivalent to
mount options=(a,b,c) options in (f),
mount options=(a,b,c) options in (g),
mount options=(d,e) options in (f),
mount options=(d,e) options in (g),
Bug Link: https://bugs.launchpad.net/apparmor/+bug/1597017
Signed-off-by: John Johansen <john.johansen@canonical.com>
- rebased to bba1a023bf
- fixed infinite loop in mnt_rule::gen_policy_re
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Acked-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit 1ec39fd437)
Signed-off-by: Jon Tourville <jon.tourville@canonical.com>
The combined optional flag and exact match flag processing is problematic
separate out the optional flag processing so it is only combined during
match string generation.
While doing so we fix the flag output so that multiple rules are
not output when they shouldn't be.
In addition we temporarily break multiple options= and 'options in'
conditionals in a single rule, which we will fix in a separate patch.
Bug Link: https://bugs.launchpad.net/apparmor/+bug/1597017
Signed-off-by: John Johansen <john.johansen@canonical.com>
- rebased to bba1a023bf
- made tests happy by changing condition in gen_policy_re()
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
Acked-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit 300889c3a4)
Signed-off-by: Jon Tourville <jon.tourville@canonical.com>
