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

[John Johansen]

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.


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

it happens enough that it is coming as a new feature, you unfortunately
just can't use it yet


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

really using the parser from the initrd is a bad idea. Ideally you 
bundle just the cache necessary for that initrd's kernel. And instead of
doing a regular profile load you do a binary load.

currently there isn't a good way to do this. But you can do it with
the parser

apparmor_parser --binary /dir/to/cache/*


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

Indeed, even the current abstractions are not designed for stricter
policies

>> 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.
> 
it helps to think about it from a profile point of view

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

The profile always controls the transition. There are different rules
to determine which transition type to use.

First the profile rule pattern that matches the executable is used

1. /a/**  ux,
2. /a/b/* Px,
3. /a/b/c ix,

any overlap between rules with different permissions have to resolved
at policy compile time, otherwise the policy compile will fail.

the general rule is exact match wins, then longest left match. The
compiler can't currently deal with dominance for overlapping expressions
so conflicting overllapping exec rules may cause the compile to fail.

but in the above set of rules, 3 is an exact match and would win if
it matces the exec, then 2, and then 1.

Once you know which rule applies you can look at the transition mode

P/p - look for profiles with a matching attachment. Note that profiles
      that don't have an explicit attachment expression use their name
      as the attachment.

C/c - same as P/p but considers children profiles instead

i - inherit current profile. No further lookup needed

u - use unconfined

-> - specify exactly which profile to transition to. So match on
     profile name not executable and attachment conditionals.

these can be combined, some so

pix - means try doing a p transition first and if no match found fallback
      to inherit.


Assuming P/p or C/c are used the next step is walking the loaded profiles
to find the best match attachment. Attachments are again based on exact
match wins, and then longest left match before regex conflict. Except this
time the resolution is done in kernel.

Once the best match profile is found, the transition to that profile is
used.

For unconfined you just need to understand that it has a single
  /** pix,

exec transition rule, so

For profile stacks, you do the above transition resultion for each profile
in the stack, and then they are combined into a new stack.

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

yep, each target in a -> is treated as a different permission so overlapping
transitions that can't be resolved will fail compile with an x conflict.

  /a/b/c -> foo,
  /a/b/* -> bar,

will work because the overlap can be resolved but

  /a/b/* -> foo,
  /a/b** -> bar,

will currently fail the compile. Even though we should be able resolve that
one with the correct dominance calculation.