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>
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>
We want to use the class field to identify operations such as
posix_mqueue
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
(cherry picked from commit 5cc7a26e78)
Signed-off-by: John Johansen <john.johansen@canonical.com>
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>
(cherry picked from commit a05c9483f3)
Signed-off-by: John Johansen <john.johansen@canonical.com>
In the [merge request that adds AppArmor support on D-Bus Broker](https://github.com/bus1/dbus-broker/pull/286), the word "method" is used instead of "member" on the auditing logs.
So we are adding support to parse "method" the same way as "member" on D-Bus audit logs.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/958
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit a96fa35bd5)
Signed-off-by: John Johansen <john.johansen@canonical.com>
... to prevent wrong/unexpected numbering (like
https://gitlab.com/apparmor/apparmor/-/issues/266) in future releases.
I propose this patch for master and 3.1.
Backporting to 3.0 and 2.x might also make sense, but of course needs a different .so number.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/915
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit bed1471144)
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
Also add one of the log lines from #271 as test_multi test case.
I propose this patch for 3.0..master.
Closes#271
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/940
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
(cherry picked from commit 0d61139e2a)
Signed-off-by: John Johansen <john.johansen@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
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
Ideally we would have a flag or something so the caller could choose
to handle symlinks, or traverse them. But since all callers currently
don't handle symlinks just handle them in the iterator.
Beyond fixing the early termination due to a failed symlink this also
fixes another case of failure in one job cause dir based loads to
terminate early. Which can result in partial loads.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/215
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/850
Signed-off-by: John Johansen <john.johansen@canonical.com>
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Library versioning requires we keep these changes in sync. Since the
3.0.4 release bumped revision we need to do it here as well.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Currently libapparmor fails to build when lto is used because it uses
the asm directive to provide different version of some symbols.
Unfortunately gcc does not recognize this and the symbols defined by
asm are lost and optimized out by lto and then the link fails.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/214
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/831
Signed-off-by: John Johansen <john.johansen@canonical.com>
The default log format for void linux is not handled by current log
parsing. The following example message results in an invalid record
error.
2021-09-11T20:57:41.91645 kern.notice: [ 469.180605] audit: type=1400 audit(1631392703.952:3): apparmor="ALLOWED" operation="mkdir" profile="/usr/bin/kak" name="/run/user/1000/kakoune/" pid=2545 comm="kak" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
This log message fails on parsing
kern.notice:
which differs from the expect syslog format of
host_name kernel:
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/196
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/799
Signed-off-by: John Johansen <john.johansen@canonical.com>
When building with YYDEBUG=1 the following failure occurs
grammar.y:49:46: error: unknown type name ‘no_debug_unused_’; did you mean ‘debug_unused_’?
void aalogparse_error(unused_ void *scanner, no_debug_unused_ char const *s)
^~~~~~~~~~~~~~~~
debug_unused_
g
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/799
Signed-off-by: John Johansen <john.johansen@canonical.com>
Adjust the interface check and fallback. Unfortunately there is no
solution that will fix all failure cases. Instead try to minimize
the failure cases and bias towards failures that don't cause a
regression under an old parser/policy.
Note: In cases where we absolutely know the interface should not
be accessed fail those accesses imediately instead of relying
on what ever LSM active to handle it.
While we are at it document the interfaces and failure cases.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/150
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/713
Signed-off-by: John Johansen <john.johansen@canonical.com>
Make it easier to separate errors from an actual answer, and ensure
we do a fallback check if there was an error.
Also fix the error code returned from aa_is_enabled() which got
broken by the addition of the private_enabled() check.
Finally make sure the private enabled error code is documented.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/150
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/713
Signed-off-by: John Johansen <john.johansen@canonical.com>
The parameter that is landing upstream in "available" not
"private_enabled".
Also set the correct variable, as previously we were not.
Note: that skipping checking available for the private apparmor
proc interfaces is okay, as the dedicated apparmor interfaces will
fail correctly if available is False.
This just gives a clear way for userspace to query this info without
having to resort to error codes that access to the private interfaces
would return.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/150
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/713
Signed-off-by: John Johansen <john.johansen@canonical.com>
libapparmor performs a test for the new stacking interface, however
how it does this test is problematic as it requires all confined
tasks to be given read access to the task introspection interface.
This results in tasks needing to be given read access to the interface
even if they don't need it. Making it possible for tasks to discover
their confinement even if they are not supposed to be able to.
Instead change the check to using stat on the parent directory.
This will generate a getattr request instead of read and make it
on the directory instead of on any interface file that could be
used to obtain information.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/150
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/713
Signed-off-by: John Johansen <john.johansen@canonical.com>
Directory traversal does not have a guaranteed walk order which can
cause ordering problems on profile loads when explicit dependencies
are missing.
Combined with MR:703 this provides a userspace work around for issue
147.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/147
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/706
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <steve.beattie@canonical.com>
There is currently a case in which proc_attr_base won't get set when
asprintf is able to generate the path, but the file doesn't exist, it
will exit proc_attr_base_init_once() without proc_attr_base having been
set as the fall-through if/else logic will get bypassed when asprintf is
successful.
libapparmor on startup does detection of whether the new stacking
proc interfaces are available and then store a var for which interface
should be used. This avoids libapparmor needing to detect which interface
to use on each proc based api call.
Unfortunately if the domain is changed on the task via change_hat or
change_profile and the proc interface is used after the domain change
it is possible that access to the interface will be denied by policy.
This is not a problem in and of it self except policy may have been
created assuming the old interface.
Fix this by adding a fallback that tries the old interface if we
are using the new interface by default and the failure was due to
an EACCES denial (policy based).
Also refactor the code a bit so this retry is isolated to one function
instead of adding it in two places.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/131
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/681
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <steve.beattie@canonical.com>
With the exception of the documentation fixes, these should all be
invisible to users.
Signed-off-by: Steve Beattie <steve.beattie@canonical.com>
Acked-by: Christian Boltz <apparmor@cboltz.de>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/687
While `_aa_asprintf` is supposed to be of private visibility, it's used
by apparmor_parser and thus required to be visible when linking. This
commit thus adds it to the list of private symbols to make it available
for linking in apparmor_parser.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
With AppArmor release 3.0, a new function `aa_features_new_from_file`
was added, but not added to the list of public symbols. As a result,
it's not possible to make use of this function when linking against
libapparmor.so.
Fix the issue by adding it to the symbol map.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Add a basic tool for manipulating the apparmor features abi via
libapparmor. This serves as a basic tool and as an example of using
the library api.
Currently its function is limited to extracting the kernel feature
abi and loading a feature abi from a file and then outputing it.
In the future it will pickup the ability to verify the feature
abi, and merge feature abis.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/613
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <steve.beattie@canonical.com>
The hashing of the featue set is wrong because it is hashing the
whole feature structure instead of just the feature string.
This results in the refcount and hash field becoming part of the
hash and the feature string not being completely hashed as the
bytes of the refcount and hash field are being counted in the
as part of the string length when the hash is taken.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/583
Reported-by: Samuele Pedroni <samuele.pedroni@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <steve.beattie@canonical.com>
Currently features doesn't provide a way to query a features
value. So add an api to extract the value string of a feature.
The value string returned is a raw text value and may contain
leading spaces, etc that the caller may need to be aware of.
Signed-off-by: John Johansen <john.johansen@canonical.com>
PDEBUG is defined away when debug isn't configure in the build, this
hides the bad format string and argument.
Fix this and make sure we can still have the debug output that was
supposed to be printed.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/561
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <sbeattie@ubuntu.com>
private.c: In function ‘_aa_is_blacklisted’:
private.c:140:35: warning: comparison of integer expressions of different signedness: ‘long int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
140 | found - name + suffix->len == name_len ) {
| ^~
private.c: In function ‘readdirfd’:
private.c:352:16: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘ssize_t’ {aka ‘long int’} [-Wsign-compare]
352 | for (i = 0; i < n; ) {
| ^
private.c:378:17: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘ssize_t’ {aka ‘long int’} [-Wsign-compare]
378 | for (i = 0; i < n; i++)
| ^
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/561
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <sbeattie@ubuntu.com>
The len parameter returns a value that correlates to a getsockopt
parameter which is typed to socklen_t which is an unsigned int.
This technically changes the fn() api but old code using this is
already broken if the getsockopt parameter is large enough to overflow
the value.
In reality what is returned shouldn't ever be negative and the value
should never be large enough to trip the overflow. This is just
cleaning up a corner case.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/561 Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <sbeattie@ubuntu.com>
kernel.c: In function ‘aa_getpeercon_raw’:
kernel.c:823:14: warning: comparison of integer expressions of different signedness: ‘socklen_t’ {aka ‘unsigned int’} and ‘int’ [-Wsign-compare]
823 | if (optlen < *len) {
| ^
kernel.c: In function ‘query_label’:
kernel.c:966:10: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
966 | if (ret != size) {
| ^~
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/561 Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <sbeattie@ubuntu.com>
```
libaalogparse.c: In function 'hex_to_string':
libaalogparse.c:144:16: warning: comparison of integer expressions of different signedness: 'int' and 'size_t' {aka 'long unsigned int'} [-Wsign-compare]
144 | for (i = 0; i < len; i++) {
| ^
```
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/558
Acked-by: John Johansen <john.johansen@canonical.com>
Following up on !549, this patchset unifies most of the compiler warnings settings to use EXTRA_WARNINGS as newly defined in `common/Make.rules` and then adds the `-Wimplicit-fallthrough` compiler warning to the default set.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/551
Acked-by: John Johansen <john.johansen@canonical.com>
```
libaalogparse.c: In function 'hex_to_string':
libaalogparse.c:144:16: warning: comparison of integer expressions of different signedness: 'int' and 'size_t' {aka 'long unsigned int'} [-Wsign-compare]
144 | for (i = 0; i < len; i++) {
| ^
```
`i` gets used/changed as counter variable in the for loop and only gets
increased (starting at 0), so making it an (unsigned) size_t should be
safe.
