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.
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.
Sorry for not replying to one of your responses John. I didn't receive
the emails, but did read the responses from the web archive.
I've made a lot of progress, but am still not quite able to fully boot
into systemd's version of init 3.
/var/log/audit/audit.log and journalctl -r doesn't show any new
"ALLOWED" entries.
I did notice this in /var/log/syslog:
May 30 10:46:51 1546-w-dev dbus-daemon[9496]: [system] Activating
systemd to hand-off: service name='org.freedesktop.hostname1'
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.21'
(uid=0 pid=10058 comm="/usr/sbin/NetworkManager --no-daemon "
label="usr.sbin.NetworkManager (complain)"
Running systemctl by itself shows no failed services, however there are
still two that never get out of "activating:"
NetworkManager.service loaded activating start start Network
Manager
systemd-logind.service loaded activating start start Login Service
Here's how I've gotten to where I have:
Running a fresh copy of a minimal install of Ubuntu 18.04.2 LTS with all
the updates. It boots into a GUI, so this isn't as minimal as CentOS's
version... or I did something wrong when installing it. :)
dpkg-query -W apparmor shows: 2.12-4ubuntu5.1
This is being ran in a vm, and I've attached minicom to the vm's kernel
"console" so that I can see everything that scrolls past and do things
like pause the output after disabling rate limiting. :)
In initramfs, I have this one profile:
profile init-systemd /lib/systemd/systemd flags=(complain
attach_disconnected) {
network,
signal,
file,
mount,
pivot_root,
ptrace,
unix,
dbus,
umount,
capability,
}
This is the version of that profile after the transition:
profile init-systemd /lib/systemd/** flags=(complain
attach_disconnected) {
capability,
network,
dbus,
mount,
umount,
signal,
ptrace,
pivot_root,
unix,
/** mrwlk,
/** Px,
}
My goal with this is to get the system into a state where I can then
start to whitelist the executables -- to that end I'm hoping this allows
everything except executing things -- to execute a separate profile must
exist. With this said, I created this file:
local/whitelist
network,
signal,
file,
mount,
pivot_root,
ptrace,
unix,
dbus,
umount,
capability,
and then wrote this little perl script to create stub files for all the
currently-existing executables:
#!/usr/bin/perl
use strict;
use warnings;
my @markedAsExecutable = `/usr/bin/find /usr/bin/ -executable -type f`;
my @applications;
foreach my $potentialExecutable (@markedAsExecutable)
{
chop($potentialExecutable);
my $isApplicationResult = `/usr/bin/file -i
'$potentialExecutable'`;
if ($isApplicationResult =~ m/\/x-/)
{
push(@applications, $potentialExecutable);
#print $isApplicationResult . "\n";
}
}
foreach my $application (@applications)
{
my $wlFileName = $application;
# replace slashes with periods
$wlFileName =~ s/\//./g;
# drop leading period if one exists
$wlFileName =~ s/^\.//;
# replace special chars with underscores for apparmor profile names
$wlFileName =~ s/[^0-9A-z.]/_/g;
#print $wlFileName . "\n";
if (! -f "/etc/apparmor.d/" . $wlFileName)
{
open FILE, ">/etc/apparmor.d/" . $wlFileName;
print FILE "profile " . $wlFileName . " \"" . $application
. "\" flags=(complain) {\n";
print FILE "\t#include <local/whitelist>\n";
print FILE "}";
close FILE;
}
}
Ran as root, this gets me almost all of the way there. There are
binaries that have a '[' in the filename and since that's a reserved
character inside apparmor's profiles, I had to manually edit some of
those profiles. It's likely there are other binaries out there with
additional special character issues -- not sure how I can make this code
deal with those automatically yet, but I could run apparmor_parser -Q
against each of these newly created files and notify the user about any
problems found.
Fun fact, Ubuntu likes to mark files like .png with the executable file
flag.
Fun fact #2, In line 1 of /usr/bin/networkd-dispatcher, there is a space
between the shebang and /usr/bin/python3. This is enough to fool "file"
into thinking that it's a plain text file even though it still
executes. There may be other files like this.
After a number of reboots and log parsing (thank you vmware snapshots!),
I had to edit these files to add "attach_disconnected" to their flags lists:
lib.systemd.systemd
lib.systemd.systemd_hostnamed
sbin.apparmor_parser
sbin.dhclient
sbin.hdparm
sbin.lvm
sbin.u_d_c_print_pci_ids
usr.bin.unshare
usr.sbin.cups-browsed
usr.sbin.cupsd
usr.sbin.gdm3
usr.sbin.NetworkManager
usr.share.apport.apport
usr.share.gdm.generate_config
I also disabled some services since they were having trouble and I
didn't need them:
avahi-daemon
wpa_supplicant
ModemManager
thermald
cups-browsed
This gets me to a login prompt and I can ssh in.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
