I've followed the wiki article here:

https://gitlab.com/apparmor/apparmor/wikis/FullSystemPolicy

However, I've got a number of questions I was hoping someone could help clarify for me. First, let me walk through what I did after step 6 (reboot after update-initramfs -u):
From the console during boot:

   Begin: Running /scripts/init-bottom ... Warning from stdin (line 1):
   /sbin/apparmor_parser: cannot use or update cache, disable, or
   forc[   36.264702] audit: type=1400 audit(1558716282.248:2):
   apparmor="STATUS" operation="profile_load" profile="unconfined"
   name="init-systemd"
   e-complain via stdin
   done.
   [   36.380094] audit: type=1400 audit(1558716282.360:3):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/etc/ld.so.cache" pid=1 comm="init" requested_mask="r"
   denied_mask="r" fsuid=0 ouid=0
   [   36.383988] audit: type=1400 audit(1558716282.364:4):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/libc-2.27.so" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   36.389412] audit: type=1400 audit(1558716282.372:5):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/libc-2.27.so" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   36.393851] audit: type=1400 audit(1558716282.376:6):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/lib/systemd/libsystemd-shared-237.so" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   36.397457] audit: type=1400 audit(1558716282.380:7):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/lib/systemd/libsystemd-shared-237.so" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   36.401758] audit: type=1400 audit(1558716282.384:8):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/librt-2.27.so" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   36.409685] audit: type=1400 audit(1558716282.392:9):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/librt-2.27.so" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   36.413464] audit: type=1400 audit(1558716282.396:10):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/libseccomp.so.2.3.1" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   36.416835] audit: type=1400 audit(1558716282.400:11):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/lib/x86_64-linux-gnu/libseccomp.so.2.3.1" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0


Now, since the init-systemd profile doesn't contain any rules, this is expected (and wanted).  However, I tried a number of things to get rid of them and only one of them worked.

First, to make sure I understand what those log entries are saying:

the "init" program is attempted to read and/or memory map certain files, however due to the init-systemd profile, if it wasn't set to complain, these actions would have been blocked.

My first thought was to create a new init profile .. something like:

   profile init /init flags=(complain) {

        # init in initramfs is at the root, not /sbin/

        /etc/ld.so.cache    r,

        /lib/**                    rm,

   }

however after adding a new apparmor_parser command to the apparmor script to load this in init-bottom, nothing changed after reboot.

So then I thought I needed to create a sub profile within the init-systemd profile for init, however, I probably didn't do this correctly, or it just won't work:

   /init        Cx -> init


   profile init flags=(complain) {

        /etc/ld.so.cache r,

        /lib/**                rm,

   }

Again, those same log entries returned.

What worked was to modify the init-systemd profile directly:

   profile init-systemd /lib/systemd/systemd flags=(complain) {

        /etc/ld.so.cache    r,
        /lib/**            rm,

   }

However, this isn't ideal because, I think, it means all things that systemd runs inherits these permissions, not just init.

I noticed something else too -- after that worked, I got a new list of additional audit messages:

   [   38.840399] audit: type=1400 audit(1558733899.848:5):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/usr/lib/x86_64-linux-gnu/libip4tc.so.0.1.0" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   38.843656] audit: type=1400 audit(1558733899.848:6):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/usr/lib/x86_64-linux-gnu/libip4tc.so.0.1.0" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   38.852170] audit: type=1400 audit(1558733899.860:7):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/usr/lib/x86_64-linux-gnu/liblz4.so.1.7.1" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   38.855990] audit: type=1400 audit(1558733899.860:8):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/usr/lib/x86_64-linux-gnu/liblz4.so.1.7.1" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   38.871219] audit: type=1400 audit(1558733899.876:9):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/usr/lib/x86_64-linux-gnu/libargon2.so.0" pid=1 comm="init"
   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
   [   38.888320] audit: type=1400 audit(1558733899.896:10):
   apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
   name="/usr/lib/x86_64-linux-gnu/libargon2.so.0" pid=1 comm="init"
   requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
   [   38.938441] audit: type=1400 audit(1558733899.944:11):
   apparmor="ALLOWED" operation="open" profile="init-systemd"
   name="/proc/filesystems" pid=1 comm="init" requested_mask="r"
   denied_mask="r" fsuid=0 ouid=0

It's like I'm only getting a few of these at a time -- I added this to the kernel boot parameter: 'audit_backlog_limit=65536' but that didn't seem to affect the number of these that I was shown. I assume some type of throttling might be occurring but there was no notice of this happening on the console.

So, now my questions:

1) Can I separate out the different "comm" matches into different profile files or do I need to maintain one monolithic file?

2) If I want to worry about restricting binaries later, but only want to "whitelist" at this point in time, is there a generic profile that I can create that will grant all permissions?

3) Why did this "Warning from stdin (line 1): /sbin/apparmor_parser: cannot use or update cache, disable, or for" disappear when I started to use profile files instead of echo for apparmor_parser?

4) Will I be able to retain the apparmor profile files that come with Ubuntu?  I assume I'll need to duplicate most of the stuff I've done in initramfs into /etc/apparmor.d somewhere?

5) How does apparmor handle multiple profiles that match on the same file?  Is the reason why my separate init profile file ignored because the init-systemd one already matched on it?

Appreciate any feedback.

-- 
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Reply via email to