af_protos.h is a generated table of the protocols created by looking
for definitions of IPPROTO_* in netinet/in.h. Depending on the
architecture, the order of the table may change when using -dM in the
compiler during the extraction of the defines.
This causes an issue because there is more than one IPPROTO defined
by the value 0: IPPROTO_IP and IPPROTO_HOPOPTS which is a header
extension used by IPv6. So if IPPROTO_HOPOPTS was first in the table,
then protocol=0 in the audit logs would be translated to hopopts.
This caused a failure in arm 32bit:
Output doesn't match expected data:
--- ./test_multi/testcase_unix_01.out 2024-08-15 01:47:53.000000000 +0000
+++ ./test_multi/out/testcase_unix_01.out 2024-08-15 23:42:10.187416392 +0000
@@ -12,7 +12,7 @@
Peer Addr: @test_abstract_socket
Network family: unix
Socket type: stream
-Protocol: ip
+Protocol: hopopts
Class: net
Epoch: 1711454639
Audit subid: 322
By the time protocol is resolved in grammar.y, we don't have have
access to the net family to check if it's inet6. Instead of making
protocol dependent on the net family, make the order of the
af_protos.h table consistent between architectures using -dD.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
(cherry picked from commit 95c419dc45)
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Unsigned int vs int probably wouldn't have caused issues, but just in case
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
(cherry picked from commit 91bac34afd)
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
This removes the assumption that the stack is zeroed and silences the corresponding compiler warning
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
(cherry picked from commit 552d9d9f7a)
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
The linkage of aa-load with the dynamic libapparmor fails with:
aa_load.c:273: undefined reference to `aa_split_overlay_str'
That is because when aa_split_overlay_str was added to libapparmor,
the function was not added to the library map.
Fixes: 50054ff0 ("add aa_split_overlay_str")
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1288
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit ed3bc55d35)
Signed-off-by: John Johansen <john.johansen@canonical.com>
- update version file
- update library version. addition of saddr/... parsing extends the
record struct which is an interface addition.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Similarly to https://gitlab.com/apparmor/apparmor/-/merge_requests/689, use the
global CFLAGS when building Python library, so we honor extra flags set by
distributions, such
as -fstack-protector-strong -fstack-clash-protection -Werror=format-security -fcf-protection.
Spotted by blhc on Debian.
Gbp-Pq: Name Honor-global-CFLAGS-when-building-Python-library.patch
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1254
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
(cherry picked from commit 1ec42d8bec)
b7d75638 Honor global CFLAGS when building Python library
Co-authored-by: Christian Boltz <apparmor@cboltz.de>
This partially reverts commit d1311cc93f.
During the cherry-pick, I incorrectly assumed the patches for fine
grained support of network rules from MR
https://gitlab.com/apparmor/apparmor/-/merge_requests/1216 were part
of apparmor-4.0, therefore the test cases added in commit d1311cc93f
fail.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
saddr, daddr, src and dest are used in network logs
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
(cherry picked from commit 6774654424)
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/397
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
audit.log entries for mount events don't always include `class=mount`,
but can still be the base for mount rules.
Change logparser.py to also consider `operation=mount` as a mount event.
Actually we already had such a log and profile in our collection
(testcase_mount_01), but since it existed years before MountRule was
implemented, it was excluded in test-libapparmor-test_multi.py.
Therefore we didn't notice that it failed to produce a profile rule when
MountRule was introduced.
Remove testcase_mount_01 from the list of known failures so that it gets
tested - and fix the syntax error in the hand-written
testcase_mount_01.profile.
Also add testcase_mount_02 which is a mount event without fstype,
srcname and class.
I propose this fix for 4.0 and master.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1229
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
(cherry picked from commit 48a936e985)
b475ed0d Handle mount events/log entries without class
Co-authored-by: Georgia Garcia <georgia.garcia@canonical.com>
We're not trying to execute a command in EXTRA_WARNINGS, so don't try to spawn
a subshell for it which gives:
```
./configure: 14770: EXTRA_WARNINGS: not found
checking whether C compiler accepts -flto-partition=none... yes
```
We can either use ${} or just $ (style). Use $ to be consistent with other
uses in the file.
Signed-off-by: Sam James <sam@gentoo.org>
The error message when autoconf-archive is not installed is not very
intuitive:
./configure: line 14422: EXTRA_WARNINGS: command not found
./configure: line 14423: syntax error near unexpected token `-flto-partition=none,'
./configure: line 14423: `AX_CHECK_COMPILE_FLAG(-flto-partition=none, , , -Werror)'
So, check if AX_CHECK_COMPILE_FLAG is defined and if not, complain
that autoconf-archive is missing.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Add missing change_profile entry required for the example
Signed-off-by: Mostafa Emami <mustafaemami@gmail.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1141
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
It appears that lto1 does not support -dynamic, and that ld no longer
documents -dynamic. Which results in the following build failure
when usine lto1 for link time optimizations
[ 45s] libtool: link: gcc -shared -fPIC -DPIC .libs/grammar.o .libs/libaalogparse.o .libs/kernel.o .libs/scanner.o .libs/private.o .libs/features.o .libs/kernel_interface.o .libs/policy_cache.o .libs/PMurHash.o -flto-partition=none -O2 -fstack-protector-strong -flto=auto -dynamic -Wl,--version-script=../src/libapparmor.map -flto=auto -pthread -Wl,-soname -Wl,libapparmor.so.1 -o .libs/libapparmor.so.1.17.0
[ 45s] lto1: warning: unrecognized gcc debugging option: y
[ 45s] lto1: warning: unrecognized gcc debugging option: n
[ 45s] lto1: warning: unrecognized gcc debugging option: m
[ 45s] lto1: warning: unrecognized gcc debugging option: i
[ 45s] lto1: warning: unrecognized gcc debugging option: c
Switch to -Bdynamic which is documented.
Signed-off-by: John Johansen <john.johansen@canonical.com>
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>
Probably thanks to O_MAYEXEC, denials for file access can now contain a
mix of x (exec) and other file permissions.
The actual exec should appear in a separate "exec" log event, therefore
ignore 'x' in file events for now if it's mixed with other permissions.
Note that file events ("open", "link" etc.) that contain denied_mask="x"
without another permission will still cause an error. (So far, this
hasn't been seen in the wild.)
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/303
Also add the log line from the bugreport and the (for now) expected
result as test_multi testcase.
The 3.1 release bumped its library version, and for consistency
needs to be bumped here as well.
Signed-off-by: John Johansen <john.johansen@canonical.com>
audit.log lines on Arch have an additional FSUID="username" OUID="username",
separated from the previous part of the log line with 0x1d.
Extend the log parsing to accept 0x1d as whitespace, and to recognize
(and ignore) FSUID and OUID.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/271
In order to decrease the number of characters in the audit logs
from the kernel, we will drop the "_mask" from the fields
"requested_mask" and "denied_mask".
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
In commit 7c7224004 ("Prepare for AppArmor 3.1 release"), as preperation
for the AppArmor 3.1.0 release, the SO versioning information was
adjusted, using a more significant bump to give prior AppArmor releases
room to address bugs in libapparmor without ending up with conflicting
SO versions. Unfortunately, that process was untested and because
AA_LIB_AGE was not incremented by the same amount as AA_LIB_CURRENT,
this resulted in an accidental major SO versions bump with the library
SO version being:
libapparmor.so.4.9.0
This commit increments AA_LIB_AGE by the same amount, resulting in a
library versioned as:
libapparmor.so.1.12.0
and adds a note to mention that AA_LIB_AGE needs to be incremented
in the same way as AA_LIB_CURRENT. This fix is intended to address
this for the 3.1 branch; I'd like to find a better approach for
the development branch that can be used in future AppArmor primary
releases.
In general, thanks to symbol versioning (see
`libraries/libapparmor/src/libapparmor.map`) we should not need to
ever bump the SO version except in an extreme case.
Fixes: 7c7224004 ("Prepare for AppArmor 3.1 release")
Signed-off-by: Steve Beattie <steve.beattie@canonical.com>
Bug: https://gitlab.com/apparmor/apparmor/-/issues/266
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/913
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
(cherry picked from commit 075c69a4eb)
f9dbaa38 [3.1] libapparmor: fix mistaken SO version bump
This change tries to give us some room to deal with versioning issues
like we had in
145136f6 Fix 2.13 libapparmor so version
which revered the library version bump in
5c47e448 libapparmor: Bump revision in preparation for release.
which was done because of the symbol added by
351014c3 libapparmor: add _aa_asprintf to private symbols
unfortunately this collided with the 3.0 library symbol versioning
which had a different set of symbols with the same version numbering.
Leaving us no way to increase the version number to when fixing an
exported symbol version in a released library.
Ideally this would have been fixed with library version synchs but
in this case that option wasn't open as we were dealing with two
released versions of the library.
Bumping the current version by 5 on the larger releases gives us room
to deal with these kind of bugs in the future.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Time-out
libraries/libapparmor/swig/python/test/buildpath.py:
The changes introduced in
cc7f549665
targetted a wrong setuptools version (61.2).
The change in build directory naming has been introduced with 62.1
(1c23f5e1e4).
