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

[Ian]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20190530/7df91afe/attachment.html>