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

2019-05-30 Thread Simon McVittie
On Thu, 30 May 2019 at 11:47:35 -0700, Ian wrote:
> 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)"

This does not, in itself, indicate a bug. Whenever dbus-daemon logs an
"interesting" action like service activation, it logs all the information
it knows about the requesting process, which on AppArmor systems includes
the AppArmor label.

(complain) means the usr.sbin.NetworkManager profile is loaded in
"complain" mode, meaning that if NM does anything that would violate its
AppArmor policy, it will be logged as ALLOWED and allowed to happen,
instead of being denied. If this is not what you wanted, please look
more closely at your AppArmor policies.

smcv

-- 
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...

2019-05-30 Thread 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