When I add a profile for some app, and this profile wants to execute or map some file, it usually wants the "x" (operation="exec") or "m" (operation="file_mmap") permissions. But what about the path the profile confines?
For instance, I have a perl script under /usr/bin/some_app . When I create
a profile for this app, the very first message in the log I can see is
the following one:
kernel: audit: type=1400 audit(1568295564.314:1537): apparmor="ALLOWED"
operation="file_mmap" \
profile="some_app" name="/usr/bin/perl" pid=55932 comm="some_app" \
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
So it is the "file_mmap" operation, but only "r" is in the "requested_mask"
field. Similar thing is with shell scripts -- they only need the read
permission on the confined file path and on some shell binary
(/usr/bin/dash).
In this case I didn't even add the perl abstraction. The only abstraction
the profile has included is the base one, so the profile's content looks
like this:
===================================
#include <tunables/global>
profile some_app /usr/bin/some_app flags=(complain) {
#include <abstractions/base>
/usr/bin/some_app r,
}
===================================
When I add "/usr/bin/perl r," the message won't appear in the log anymore.
Shouldn't be here some "x" or "m" permissions, or maybe AppArmor assumes
this automatically for the confined path, so it's redundant to specify it
manually?
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
