[apparmor] Question about file_mmap/exec in the case of perl/shell scripts

[Mikhail Morfikov]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20190912/c574ab6b/attachment.sig>