Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...
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
Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...
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
signature.asc
Description: PGP signature
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...
I've followed the wiki article here:
https://gitlab.com/apparmor/apparmor/wikis/FullSystemPolicy
However, I've got a number of questions I was hoping someone could help
clarify for me.
First, let me walk through what I did after step 6 (reboot after
update-initramfs -u):
From the console during boot:
Begin: Running /scripts/init-bottom ... Warning from stdin (line 1):
/sbin/apparmor_parser: cannot use or update cache, disable, or
forc[ 36.264702] audit: type=1400 audit(1558716282.248:2):
apparmor="STATUS" operation="profile_load" profile="unconfined"
name="init-systemd"
e-complain via stdin
done.
[ 36.380094] audit: type=1400 audit(1558716282.360:3):
apparmor="ALLOWED" operation="open" profile="init-systemd"
name="/etc/ld.so.cache" pid=1 comm="init" requested_mask="r"
denied_mask="r" fsuid=0 ouid=0
[ 36.383988] audit: type=1400 audit(1558716282.364:4):
apparmor="ALLOWED" operation="open" profile="init-systemd"
name="/lib/x86_64-linux-gnu/libc-2.27.so" pid=1 comm="init"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 36.389412] audit: type=1400 audit(1558716282.372:5):
apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
name="/lib/x86_64-linux-gnu/libc-2.27.so" pid=1 comm="init"
requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
[ 36.393851] audit: type=1400 audit(1558716282.376:6):
apparmor="ALLOWED" operation="open" profile="init-systemd"
name="/lib/systemd/libsystemd-shared-237.so" pid=1 comm="init"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 36.397457] audit: type=1400 audit(1558716282.380:7):
apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
name="/lib/systemd/libsystemd-shared-237.so" pid=1 comm="init"
requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
[ 36.401758] audit: type=1400 audit(1558716282.384:8):
apparmor="ALLOWED" operation="open" profile="init-systemd"
name="/lib/x86_64-linux-gnu/librt-2.27.so" pid=1 comm="init"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 36.409685] audit: type=1400 audit(1558716282.392:9):
apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
name="/lib/x86_64-linux-gnu/librt-2.27.so" pid=1 comm="init"
requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
[ 36.413464] audit: type=1400 audit(1558716282.396:10):
apparmor="ALLOWED" operation="open" profile="init-systemd"
name="/lib/x86_64-linux-gnu/libseccomp.so.2.3.1" pid=1 comm="init"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 36.416835] audit: type=1400 audit(1558716282.400:11):
apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
name="/lib/x86_64-linux-gnu/libseccomp.so.2.3.1" pid=1 comm="init"
requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
Now, since the init-systemd profile doesn't contain any rules, this is
expected (and wanted). However, I tried a number of things to get rid
of them and only one of them worked.
First, to make sure I understand what those log entries are saying:
the "init" program is attempted to read and/or memory map certain files,
however due to the init-systemd profile, if it wasn't set to complain,
these actions would have been blocked.
My first thought was to create a new init profile .. something like:
profile init /init flags=(complain) {
# init in initramfs is at the root, not /sbin/
/etc/ld.so.cache r,
/lib/** rm,
}
however after adding a new apparmor_parser command to the apparmor
script to load this in init-bottom, nothing changed after reboot.
So then I thought I needed to create a sub profile within the
init-systemd profile for init, however, I probably didn't do this
correctly, or it just won't work:
/init Cx -> init
profile init flags=(complain) {
/etc/ld.so.cache r,
/lib/** rm,
}
Again, those same log entries returned.
What worked was to modify the init-systemd profile directly:
profile init-systemd /lib/systemd/systemd flags=(complain) {
/etc/ld.so.cache r,
/lib/** rm,
}
However, this isn't ideal because, I think, it means all things that
systemd runs inherits these permissions, not just init.
I noticed something else too -- after that worked, I got a new list of
additional audit messages:
[ 38.840399] audit: type=1400 audit(1558733899.848:5):
apparmor="ALLOWED" operation="open" profile="init-systemd"
name="/usr/lib/x86_64-linux-gnu/libip4tc.so.0.1.0" pid=1 comm="init"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[ 38.843656] audit: type=1400 audit(1558733899.848:6):
apparmor="ALLOWED" operation="file_mmap" profile="init-systemd"
name="/usr/lib/x86_64-linux-gnu/libip4tc.so.0.1.0" pid=1 comm="init"
requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
[ 38.852170] audit: type=1400 audit(1558733899.860:7):
apparmor="ALLOWED"
