[apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...

Ian apparmor at zestysoft.com
Fri May 31 19:27:45 UTC 2019


On 5/30/19 12:04 PM, Simon McVittie wrote:
> On Thu, 30 May 2019 at 11:47:35 -0700, Ian wrote:
>> I did notice this in /var/log/syslog:
>>
>>      May 30 10:46:51 1546-w-dev dbus-daemon[9496]: [system] Activating systemd
>>      to hand-off: service name='org.freedesktop.hostname1' unit=
>>      'dbus-org.freedesktop.hostname1.service' requested by ':1.21' (uid=0 pid=
>>      10058 comm="/usr/sbin/NetworkManager --no-daemon " label=
>>      "usr.sbin.NetworkManager (complain)"
> This does not, in itself, indicate a bug. Whenever dbus-daemon logs an
> "interesting" action like service activation, it logs all the information
> it knows about the requesting process, which on AppArmor systems includes
> the AppArmor label.
>
> (complain) means the usr.sbin.NetworkManager profile is loaded in
> "complain" mode, meaning that if NM does anything that would violate its
> AppArmor policy, it will be logged as ALLOWED and allowed to happen,
> instead of being denied. If this is not what you wanted, please look
> more closely at your AppArmor policies.
>
>      smcv

Simon, thanks for clearing that one up.

I was able to get the system to fully boot by changing

       /** Px,

to

       /** px,

in the lib.systemd.systemd post chroot profile.

The only thing outstanding is some trouble I run into after the 
initramfs chroot transition but before the apparmor service starts:

    May 31 12:10:55 1546-w-dev audit[5162]: AVC apparmor="ALLOWED"
    operation="exec" info="profile transition not found" error=-13
    profile="init-sys
    temd" name="/usr/bin/unshare" pid=5162 comm="(spawn)"
    requested_mask="x" denied_mask="x" fsuid=0 ouid=0
    target="/usr/bin/unshare"
    May 31 12:10:54 1546-w-dev audit[5004]: AVC apparmor="ALLOWED"
    operation="exec" info="profile transition not found" error=-13
    profile="init-sys
    temd" name="/usr/bin/unshare" pid=5004 comm="(spawn)"
    requested_mask="x" denied_mask="x" fsuid=0 ouid=0
    target="/usr/bin/unshare"


    [   42.159486] apparmor[635]:  * Starting AppArmor profiles

    [   49.102218] [5004]: failed to execute '/usr/bin/unshare'
    '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sda1':
    Permission denied
    [   49.106734] systemd-udevd[699]: Process '/usr/bin/unshare -m
    /usr/bin/snap auto-import --mount=/dev/sda1' failed with exit code 2.

    [   49.119734] [5162]: failed to execute '/usr/bin/unshare'
    '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/dm-1':
    Permission denied
    [   49.124361] systemd-udevd[5160]: Process '/usr/bin/unshare -m
    /usr/bin/snap auto-import --mount=/dev/dm-1' failed with exit code 2.

    [  *** ] A start job is running for AppArmor initialization (15s /
    no limit)

    [   56.349850] auditd[753]: Audit daemon rotating log files
    [  OK  ] Started AppArmor initialization.

The /usr/sbin/unshare profile exists:

    root at 1546-w-dev:/etc/apparmor.d# cat usr.bin.unshare
    profile usr.bin.unshare /usr/bin/unshare
    flags=(complain,attach_disconnected) {
         #include <local/whitelist>
    }


    root at 1546-w-dev:/etc/apparmor.d# cat local/whitelist
         network,
         signal,
         mount,
         pivot_root,
         ptrace,
         unix,
         dbus,
         umount,
         capability,
         / mrwlk,
         /** mrwlk,
         /** px,

As does /usr/bin/snap profile:

    root at 1546-w-dev:/etc/apparmor.d# cat usr.bin.snap
    profile usr.bin.snap /usr/bin/snap
    flags=(complain,attach_disconnected) {
         #include <local/whitelist>
    }

aa-status shows both of these loaded under "complain".

Is this a timing thing?  Something attempting to load as apparmor 
transitions? I.E. apparmor is still loading profiles when 
/usr/bin/unshare is being executed?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20190531/b0164189/attachment.html>


More information about the AppArmor mailing list