Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...
On 5/27/19 5:11 PM, Ian wrote: > > On 5/27/19 12:08 PM, Ian wrote: >> >> 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? >> >> >> > Adding "attach_disconnected" to the flags parameter of the init-systemd > profile was required to get the system to fully boot. I assume this was > necessary because of the transition from initramfs, however the "ALLOWED" > audit log entries really threw me there -- that and my ability to run lots of > other commands without issue in that "emergency" mode didn't make this an > obvious fix. > yes this is a pita, and logs getting dropped make it worse. I don't have a good solution in the short term. Long term, the audit parts are getting reworked and will be able to do better dedup and caching to reduce auditing load, and allow for devs to create a large log buffer to properly profile early boot. > This initramfs transition is a tricky bit of business -- that it is > I assume I'll want to have a different profile for systemd for the chrooted > system and that when the apparmor service starts, that is probably best but may not be necessary depending on the privileges you are granting > the profile will get replaced, however I thought that profile changes like > this aren't seen by currently executing processes -- one has to restart the > process for the change to take effect? Actually as long as the profile is already attached to the task, profile replacement will be picked up. However there is no guarantee that it will be atomic across all tasks. That is to say the update happens on a best effort case, and the old and new version of the profile may be alive at the same time for a window. Exactly how long depends on locking and scheduling etc. Profiles for a task will only be updated when the task is running, etc. What currently can't be done is changing the confinement of a task from one profile to another. The task must be either "security aware" and do this it self or be re-execed. > Then there's the timing of when journald and auditd starts. Ideally I'd like > to keep the full-permission profile I set up in inittamfs for systemd, but > then somehow deny any type of inheritance once the AppArmor service starts. > you should be able to achieve this with just a profile load in the apparmor service. Replacing the existing profiles that were already loaded from the initrd. It of course has the above mentioned limitations > Any advice on how to proceed? -- If it is true that all child processes will, > by default, inherit the permissions from the init-systemd profile unless I > add deny rules -- I'm back at square one with a blacklist setup. > > it will depend on your init-systemd profile. If it uses ix for exec transitions then every child will inherit its confinement. However if you use px or even pix and have profiles definied for those children then they should have different confinement and you should be okay. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...
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.
>
Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...
On 5/27/19 12:08 PM, Ian wrote: 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? Adding "attach_disconnected" to the flags parameter of the init-systemd profile was required to get the system to fully boot. I assume this was necessary because of the transition from initramfs, however the "ALLOWED" audit log entries really threw me there -- that and my ability to run lots of other commands without issue in that "emergency" mode didn't make this an obvious fix. This initramfs transition is a tricky bit of business -- I assume I'll want to have a different profile for systemd for the chrooted system and that when the apparmor service starts, the profile will get replaced, however I thought that profile changes like this aren't seen by currently executing processes -- one has to restart the process for the change to take effect? Then there's the timing of when journald and auditd starts. Ideally I'd like to keep the full-permission profile I set up in inittamfs for systemd, but then somehow deny any type of inheritance once the AppArmor service starts. Any advice on how to proceed? -- If it is true that all child processes will, by default, inherit the permissions from the init-systemd profile unless I add deny rules -- I'm back at square one with a blacklist setup. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] Attempting FullSystemPolicy with Ubuntu 18.04.2 LTS...
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:
