On 5/27/19 12:08 PM, Ian wrote:
>
> 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,
>
> }
>
unfortunately you will need flags=(attach_disconnected)
this is partly because of the initial pivot root but also for services that systemd starts in an another namespace.
Curently apparmor does not support this well. Delegation is supposed to be the primary means of dealing with this but we have not been able to land delegation yet
> aar -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 certainly allows for security aware programs, and if the profile allows it, they could transition to unconfined, but I don't think this is your problem.
policy needs to be loaded early enough to be attached to tasks, the target needs to be visible to the namespace, and systemd needs to re-exec it self after policy load. The above "disconnect path" errors show show of the things being run aren't visible and hence failing. This can be "fixed" by adding attach disconnected.
The other part of the problem is having policy loaded early enough. This is problematic on systemd. I have not done this part on a systemd system yet. Last I messed with early policy in the initrd was an upstart based system where upstart wasn't the init process in the initrd. This allowed me to change the exec to upstart to be essentially
aa-exec -p init-profile -- upstart
This is harder with systemd, as the initrd systemd should do the early setup and pivot and then re-exec it self, however from what work I have done on integrating early apparmor policy load into systemd this is not what needs to be done, since systemd is the early init process. Systemd needs to be "security aware", it needs to do the early policy load, and then it needs to set confinement on itself. This all needs to be done before systemd starts firing off new processes.
I have started systemd patches for apparmor, but they aren't done. Its been a while since I have worked on them but I can dig up the branch and push it to gitlab this week if you are interested. I should note that this will at a minimum require apparmor 2.13 for systemd to be linked against.