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>
The inetutils syslogd implementation integrates the kmsg support in the
main server, it has support for syslog.d configuration fragment files.
and it uses a slightly different pid filename.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/888
Approved-by: Steve Beattie <gitlab@nxnw.org>
Merged-by: Steve Beattie <gitlab@nxnw.org>
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.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/896
Approved-by: Christian Boltz <apparmor@cboltz.de>
Approved-by: Jon Tourville <jon.tourville@canonical.com>
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.
Tuples [are quite a bit faster than lists](https://stackoverflow.com/a/22140115). If you don't need mutability, a tuple is almost always the better collection to choose. This merge request changes lists to tuples where appropriate, and speeds up some list creations by changing `list()` calls into `[]` literals. It also changes a few function calls to use tuple unpacking, i.e. `func(*tup)`, as opposed to `func(tup[0], tup[1], ...)`. This yields yet another performance improvement, as well as a readability improvement.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/889
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
The inetutils syslogd implementation integrates the kmsg support in the
main server, it has support for syslog.d configuration fragment files.
and it uses a slightly different pid filename.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
This partially addresses issue #239. There are still some remaining instances where opened files are not properly closed, e.g. the `NamedTemporaryFile` in `utils/apparmor/config.py`.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/885
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
I found a few spelling and grammar errors while working on my other merge requests. I figured it'd be wise to separate these fixes from the code changes.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/887
Approved-by: Christian Boltz <apparmor@cboltz.de>
Merged-by: Christian Boltz <apparmor@cboltz.de>
Abstractions should not generally include deny rules as this can unduly
constrain profiles which include them due to the precedent matching rules
between deny vs allow rules. Also as per the comment, this is not required
for exo-open to work, so simply omit it from the abstraction for
now. Finally, in Ubuntu, the evince profile includes the exo-open
abstraction and this deny rule causes evince to fail to initialise
correctly as it then assumes it cannot use gvfs.
Signed-off-by: Alex Murray <alex.murray@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/884
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
Abstractions should not generally include deny rules as this can unduly
constrain profiles which include them due to the precedent matching rules
between deny vs allow rules. Also as per the comment, this is not required
for exo-open to work, so simply omit it from the abstraction for
now. Finally, in Ubuntu, the evince profile includes the exo-open
abstraction and this deny rule causes evince to fail to initialise
correctly as it then assumes it cannot use gvfs.
Signed-off-by: Alex Murray <alex.murray@canonical.com>
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>
I noticed that some apps return the following errors when launched:
```
kernel: audit: type=1400 audit(1651244478.255:5501): apparmor="DENIED" operation="open" profile="some_app" name="/sys/devices/pci0000:00/0000:00:02.0/revision" pid=1877976 comm="some_app" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
kernel: audit: type=1400 audit(1651244478.255:5502): apparmor="DENIED" operation="open" profile="some_app" name="/sys/devices/pci0000:00/0000:00:02.0/config" pid=1877976 comm="some_app" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
```
Blocking the files results in the following errors when the app is executed in a terminal:
```
MESA: error: Failed to query drm device.
libGL error: failed to create dri screen
libGL error: failed to load driver: crocus
MESA: error: Failed to query drm device.
libGL error: failed to create dri screen
libGL error: failed to load driver: crocus
```
Since they have something to do with MESA, I think the mesa abstraction should
be updated to fix the issue.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/879
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
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 |
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/882
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
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 |
aarch64 needs some additional rules on tumbleweed to handle for
example
apparmor="DENIED" operation="file_mmap" profile="samba-dcerpcd" name="/usr/lib64/samba/samba-dcerpcd" pid=897 comm="samba-dcerpcd" requested_mask="m" denied_mask="m" fsuid=0 ouid=0
The other new rpcd_* services exhibit similar errors
Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1198309
Signed-off-by: Noel Power <noel.power@suse.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/880
Approved-by: Christian Boltz <apparmor@cboltz.de> for 3.0 and master
Merged-by: Christian Boltz <apparmor@cboltz.de>
aarch64 needs some additional rules on tumbleweed to handle for
example
apparmor="DENIED" operation="file_mmap" profile="samba-dcerpcd" name="/usr/lib64/samba/samba-dcerpcd" pid=897 comm="samba-dcerpcd" requested_mask="m" denied_mask="
The other new rpcd_* services exhibit similar errors
Fixes: https://bugzilla.opensuse.org/show_bug.cgi?id=1198309
Signed-off-by: Noel Power <noel.power@suse.com>
I noticed that some apps return the following errors when launched:
kernel: audit: type=1400 audit(1651244478.255:5501): apparmor="DENIED" operation="open" profile="some_app" name="/sys/devices/pci0000:00/0000:00:02.0/revision" pid=1877976 comm="some_app" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
kernel: audit: type=1400 audit(1651244478.255:5502): apparmor="DENIED" operation="open" profile="some_app" name="/sys/devices/pci0000:00/0000:00:02.0/config" pid=1877976 comm="some_app" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Blocking the files results in the following errors when the app is executed in a terminal:
MESA: error: Failed to query drm device.
libGL error: failed to create dri screen
libGL error: failed to load driver: crocus
MESA: error: Failed to query drm device.
libGL error: failed to create dri screen
libGL error: failed to load driver: crocus
Since they have something to do with MESA, I think the mesa abstraction should
be updated to fix the issue.
The snap_browsers abstraction requires more permissions
due to updates on snaps.
Some of the permissions are not required in older versions of
Ubuntu that use 2.12 and 2.13, but are introduced for unification
and ease of maintenance purposes. These include:
```
all dbus permissions,
@{PROC}/sys/kernel/random/uuid r,
owner @{PROC}/@{pid}/cgroup r,
/var/lib/snapd/sequence/{chromium,firefox,opera}.json r,
```
I also propose a cherry-pick of this commit to 2.12, 2.13 and 3.0
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/877
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
The snap_browsers abstraction requires more permissions
due to updates on snaps.
Some of the permissions are not required in older versions of
Ubuntu that use 2.12 and 2.13, but are introduced for unification
and ease of maintenance purposes. These include:
all dbus permissions,
@{PROC}/sys/kernel/random/uuid r,
owner @{PROC}/@{pid}/cgroup r,
/var/lib/snapd/sequence/{chromium,firefox,opera}.json r,
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
