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?


-- 
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Reply via email to