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

[Seth Arnold]

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

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

You can't filter directly on comm. (You can do the profile transitions on
exec, though, as you already know.)

> 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,
}

> 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?

The filename used for the compiled cache files is based on the filename of
the input files.

> 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?

Likely these will need some changes. You'll probably want more strict
profiles than we've provided, anyway, since we've written the profiles
with the contrasting goals of providing some safety but without too
much compromise in useability. If you're doing this full-system policy
investigation you'll probably want to make different tradeoffs than
we have.

> 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?

This is a bit involved.

There's attachments using attachment specifications from unconfined
processes and Px rules with wildcards, then there's profile-directed
transitions.

When going from unconfined to confined, or when using a Px rule where at
least some of the pathname is written with wildcards or other globbing,
then AppArmor will try to apply policy in the order of most specific to
least specific name. A profile attachment without wildcards should beat a
profile with wildcards or globbing. Multiple profile attachments with
wildcards or globs should pick the longest match.

Profile-directed transitions (-> in the rules) will take precedence
over the attachment-directed transitions. I believe in this case every
execution must have exactly one possible outcome but I'm less sure
of this.

I hope this helps.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20190524/49b1b578/attachment.sig>