aa-load is a tool that loads cached (compiled) policies into
the kernel. It can receive as argument a file, a cache directory
containing the hash subtree, and a directory containing cached
files directly underneath - no hash.
This tool can be used in the as a guide for other init
systems to load the cached policies directly.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/770
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
This Fixes coverity CID 254463: Memory - illegal accesses (USE_AFTER_FREE)
which was introduced in 35e58273 / https://gitlab.com/apparmor/apparmor/-/merge_requests/713 (merged)
The coverity report it self is wrong because while the pointer use is
after free. It is deliberately a pointer comparison to see if the
value was pointing to proc_attr_base_old. This is not actually
problematic as far as it goes. However it does surface a bug in the
logic, and regardless if it is allowed doing a post-free pointer
comparison like this will confuse static checkers and humans alike.
procattr_path() will never return proc_attr_base_old, it will return a
copy of it (if it did return it, we couldn't free it). So the test tmp
!= proc_attr_base_old is bad, in that it will always be true even if
tmp was a copy of proc_attr_base_old.
Fix this by makint tmp auto free, and switching to a string comparison.
Signed-off-by: John Johansen <john.johansen@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1042
Aked-by: time-out
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
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1054
Signed-off-by: John Johansen <john.johansen@canonical.com>
(cherry picked from commit 86d193e183)
Signed-off-by: John Johansen <john.johansen@canonical.com>
... to avoid returning it uninitialized.
Found by coverity: CID 320935: Uninitialized variables (UNINIT)
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1053
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
This Fixes coverity CID 254463: Memory - illegal accesses (USE_AFTER_FREE)
which was introduced in 35e58273 / https://gitlab.com/apparmor/apparmor/-/merge_requests/713 (merged)
The coverity report it self is wrong because while the pointer use is
after free. It is deliberately a pointer comparison to see if the
value was pointing to proc_attr_base_old. This is not actually
problematic as far as it goes. However it does surface a bug in the
logic, and regardless if it is allowed doing a post-free pointer
comparison like this will confuse static checkers and humans alike.
procattr_path() will never return proc_attr_base_old, it will return a
copy of it (if it did return it, we couldn't free it). So the test tmp
!= proc_attr_base_old is bad, in that it will always be true even if
tmp was a copy of proc_attr_base_old.
Fix this by makint tmp auto free, and switching to a string comparison.
Signed-off-by: John Johansen <john.johansen@canonical.com>
... so that each change in master gets scanned (until we reach the scan
limit).
This will give us more timely results than only scanning the coverity
branch whenever someone manually updates it.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1052
Approved-by: John Johansen <john@jjmx.net>
Merged-by: Christian Boltz <apparmor@cboltz.de>
... so that each change in master gets scanned (until we reach the scan
limit).
This will give us more timely results than only scanning the coverity
branch whenever someone manually updates it.
I have been testing the `usr.sbin.sshd` profile with the [three "for internal-sftp" rules](ad3750058d/profiles/apparmor/profiles/extras/usr.sbin.sshd (L138-140)) commented out, as they are quite broad. This has turned up a few oversights, a couple of which have been fixed in abstractions. This MR brings in the missing rules that don't currently seem to have a better place to go, and addresses a couple of other minor issues in the profile.
Here are the associated syslog messages:
```
Jun 8 21:09:11 testvm kernel: [ 28.211637] audit: type=1400 audit(1686272951.369:66): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/sshd" name="/run/systemd/notify" pid=830 comm="sshd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
Jun 9 00:27:24 testvm kernel: [10846.886139] audit: type=1400 audit(1686284844.516:1268): apparmor="DENIED" operation="mkdir" profile="/usr/sbin/sshd" name="/home/username/.cache/" pid=5815 comm="sshd" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
Jun 9 00:28:57 testvm kernel: [10940.152625] audit: type=1400 audit(1686284937.780:1337): apparmor="DENIED" operation="mknod" profile="/usr/sbin/sshd" name="/home/username/.cache/motd.legal-displayed" pid=5979 comm="sshd" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
```
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1051
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
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>
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>
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
Signed-off-by: Georgia Garcia <georgia.garcia@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>
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>
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
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
If `else if (preprocess_only)` is true, the more strict condition
`else if (!include_file && preprocess_only)` won't be reached if it gets
checked after the shorter condition.
Exchange the two sections so that both code paths can be reached.
Fixes coverity CID 312499: Control flow issues (DEADCODE)
This was probably introduced in 7dcf013bca / https://gitlab.com/apparmor/apparmor/-/merge_requests/743 which means we'll need to backport this fix to 3.0 and 3.1.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1039
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: John Johansen <john@jjmx.net>
... by including cstdint.
Credits go to the new gcc in Tumbleweed for proposing this patch.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1038
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: John Johansen <john@jjmx.net>
If `else if (preprocess_only)` is true, the more strict condition
`else if (!include_file && preprocess_only)` won't be reached if it gets
checked after the shorter condition.
Exchange the two sections so that both code paths can be reached.
Fixes coverity CID 312499: Control flow issues (DEADCODE)
In some cases (if profiles in complain _and_ enforce mode are loaded), the `i` loop runs more
than once, which also means `j == 0` is true in the middle of the json.
This causes invalid json.
This patch fixes this.
This is a regression related to 22aa9b6161
/ https://gitlab.com/apparmor/apparmor/-/merge_requests/964 /
https://gitlab.com/apparmor/apparmor/-/issues/295
which fixed another case of invalid json if a process was unconfined
while having a profile defined.
Note: I also tested this patch for the "unconfined, but has a profile
defined" case to ensure it doesn't break what
22aa9b6161 fixed.
This fix is needed in all branches that also got !964 (which means 3.1 and 3.0).
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1036
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
In some cases (if profiles in complain and enforce mode are loaded), the
`i` loop runs more than once, which also means `j == 0` is true in the
middle of the json. This causes invalid json.
This patch fixes this.
This is a regression related to 22aa9b6161
/ https://gitlab.com/apparmor/apparmor/-/merge_requests/964 /
https://gitlab.com/apparmor/apparmor/-/issues/295
which fixed another case of invalid json if a process was unconfined
while having a profile defined.
Note: I also tested this patch for the "unconfined, but has a profile
defined" case to ensure it doesn't break what
22aa9b6161 fixed.
Enhance aa-status by adding posix regex filter support and support for new modes
this MR adds the following command line options
```
--show={profiles,processes,all}
--count
--filter.mode=filter
--filter.processs=filter
--filter.profiles=filter
--filter.pid=filter
```
Where currently filters use the basic posix regexs, do we want to go with extended regex, or apparmor globbing
An example of using the new filters
```
$ sudo ./aa-status --filter.exe="firefox" --show=processes
apparmor module is loaded.
65 processes have profiles defined.
25 processes are in enforce mode.
/snap/firefox/2605/usr/lib/firefox/firefox (4406) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (4686) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (4721) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (4826) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (19204) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (19206) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (23159) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (23195) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (23292) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (30929) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (31487) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (31528) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (71708) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2271631) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2271969) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2272030) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2272347) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2654995) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2655042) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2655082) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2655152) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2655237) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2656215) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2656334) snap.firefox.firefox
/snap/firefox/2605/usr/lib/firefox/firefox (2657837) snap.firefox.firefox
0 processes are in complain mode.
0 processes are in prompt mode.
0 processes are in kill mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
```
Signed-off-by: John Johansen <john.johansen@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1016
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: John Johansen <john@jjmx.net>
Bring in updates and improvements that have been made to the Chromium profile at `apparmor-profiles/ubuntu/20.04/usr.bin.chromium-browser`.
The changes are largely as follows:
* Use `@{pid}` or `@{tid}` instead of `[0-9]*`
* Use the discrete `lsb_release` profile instead of a subprofile
* Add a few additional libraries to the `sandbox` subprofile
Once this is in, the Chromium profiles in `apparmor-profiles` can be considered deprecated, and I would advise slating them for removal altogether.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1032
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: John Johansen <john@jjmx.net>
`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>
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>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1024
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-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>
To emphasize that the
--mode
--processs
--profiles
--pid
options are filters rename them to
--filter.mode
--filter.processs
--filter.profiles
--filter.pid
Signed-off-by: John Johansen <john.johansen@canonical.com>
