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

Mon May 27 19:08:44 UTC 2019

On 5/24/19 6:16 PM, John Johansen wrote:
> On 5/24/19 5:10 PM, Seth Arnold wrote:
>> On Fri, May 24, 2019 at 03:28:21PM -0700, Ian wrote:
>>> 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.
>> Hello Ian,
>>
>> The audit_backlog_limit parameter likely only applies to the auditd
>> daemon. If your audit messages are written to dmesg instead, you'll
>> reach a different rate limiting method. (Though I thought that one would
>> include a message about printk rate limits being hit.)
>>
>> Regular printk message rate can be controlled via
>> /proc/sys/kernel/printk_ratelimit
>> /proc/sys/kernel/printk_ratelimit_burst
>> details are in the kernel source file Documentation/sysctl/kernel.txt
>>
> yes, if auditd isn't registered messages will go to the kernel ring
> buffer and printk_ratelimit is used.
>
> there is a warning message that audit messages are lost, however it
> may not always trigger. Depending on what triggered the loss, failure
> mode etc.

That was what I needed.  I thought I was limited to kernel boot 
parameters and apparently printk_ratelimit wasn't one of them.

>>> 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?
>> We should probably write a tool to generate one appropriate for the system
>> it's on, since it's not obvious how to do this by hand. But "Allow
>> Everything" profiles probably shouldn't be the norm, so maybe a little
>> friction is worthwhile.
>>
>> Anyway, it would look something like:
>>
>> profile profilename /attachment/specification {
>>    network,
>>    signal,
>>    file,
>>    mount,
>>    pivot_root,
>>    ptrace,
>>    unix,
>>    dbus,
>> }
>>
> it happens enough that it is coming as a new feature, you unfortunately
> just can't use it yet

No worries, I used that list (plus 'umount', and 'capability') to quiet 
the audit output for systemd while it was doing things before 
transitioning.  At this point all I'm trying to do is mimic how the 
system currently boots without Apparmor enabled.  I'm not currently able 
to fully boot into the system since two services "systemd-resolved" and 
"sytemd-udevd" fail to finish loading.

For instance, if I add the kernel parameter "emergency" so that I boot 
directly to shell after initramfs, remount root as rw, and attempt to 
start the resolve service, I get this:

    # systemctl start systemd-resolved
    [  701.817178] systemd[1]: Starting Network Name Resolution...
    [  701.821550] systemd[411]: systemd-resolved.service: Failed to
    connect stdout to the journal socket, ignoring: No such file or
    directory
    [  701.904706] audit: type=1400 audit(1558982354.096:69):
    apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
    disconnected path" error=-13 profile="init-systemd"
    name="run/systemd/notify" pid=411 comm="systemd-resolve"
    requested_mask="w" denied_mask="w" fsuid=10
    [  701.908775] audit: type=1400 audit(1558982354.096:70):
    apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
    disconnected path" error=-13 profile="init-systemd"
    name="run/systemd/notify" pid=411 comm="systemd-resolve"
    requested_mask="r" denied_mask="r" fsuid=10
    [  701.912779] audit: type=1400 audit(1558982354.096:71):
    apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
    disconnected path" error=-13 profile="init-systemd"
    name="run/systemd/notify" pid=411 comm="systemd-resolve"
    requested_mask="w" denied_mask="w" fsuid=10
    [  701.916948] audit: type=1400 audit(1558982354.096:72):
    apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
    disconnected path" error=-13 profile="init-systemd"
    name="run/systemd/notify" pid=411 comm="systemd-resolve"
    requested_mask="r" denied_mask="r" fsuid=10
    [  791.827056] systemd[1]: systemd-resolved.service: Start operation
    timed out. Terminating.
    [  791.834261] audit: type=1400 audit(1558982444.024:73):
    apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
    disconnected path" error=-13 profile="init-systemd"
    name="run/systemd/notify" pid=411 comm="systemd-resolve"
    requested_mask="w" denied_mask="w" fsuid=10
    [  791.857002] audit: type=1400 audit(1558982444.024:74):
    apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
    disconnected path" error=-13 profile="init-systemd"
    name="run/systemd/notify" pid=411 comm="systemd-resolve"
    requested_mask="r" denied_mask="r" fsuid=10
    [  791.869512] audit: type=1400 audit(1558982444.048:75):
    apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
    disconnected path" error=-13 profile="init-systemd"
    name="run/systemd/notify" pid=411 comm="systemd-resolve"
    requested_mask="w" denied_mask="w" fsuid=10
    [  791.874754] audit: type=1400 audit(1558982444.048:76):
    apparmor="ALLOWED" operation="sendmsg" info="Failed name lookup -
    disconnected path" error=-13 profile="init-systemd"
    name="run/systemd/notify" pid=411 comm="systemd-resolve"
    requested_mask="r" denied_mask="r" fsuid=10
    [  791.896770] systemd[1]: systemd-resolved.service: Failed with
    result 'timeout'.
    [  791.898386] systemd[1]: Failed to start Network Name Resolution.
    [  791.899824] systemd[1]: systemd-resolved.service: Service has no
    hold-off time, scheduling restart.
    [  791.901531] systemd[1]: systemd-resolved.service: Scheduled
    restart job, restart counter is at 1.
    Job for systemd-resolved.service failed because [  791.903237]
    systemd[1]: Stopped Network Name Resolution.
    a timeout was exceeded.
    See "systemctl status systemd-resolved.service" and "journalctl -xe"
    for details.

Mind you, this is with the init-systemd profile set to this:

    profile init-systemd /lib/systemd/systemd flags=(complain) {
    network,
    signal,
    file,
    mount,
    pivot_root,
    ptrace,
    unix,
    dbus,
    umount,
    capability,

    }

aa-status shows nothing enforcing:

    # aa-status
    apparmor module is loaded.
    1 profiles are loaded.
    0 profiles are in enforce mode.
    1 profiles are in complain mode.
    init-systemd
    7 processes have profiles defined.
    0 processes are in enforce mode.
    7 processes are in complain mode.
        init-systemd (1)
        init-systemd (321)
        init-systemd (322)
        init-systemd (323)
        init-systemd (324)
        init-systemd (451)
        init-systemd (454)
    0 processes are unconfined but have a profile defined.

#ps auxZ shows this:

    init-systemd (complain)         systemd+   457  0.1  0.1 70624  5120
    ?        Ss   11:51   0:00 /lib/systemd/systemd-resolved

Does apparmor have the same problem as selinux where there are "security 
aware" programs that don't properly honor enforcement settings, or is 
this an inheritance problem that I'm not correctly addressing?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20190527/5d5f1ed3/attachment-0001.html>