Hi,
Peter Palfrader wrote (20 Oct 2015 18:50:38 GMT) :
> On Tue, 20 Oct 2015, intrigeri wrote:
>> If AppArmorProfile= is applied _after_ ExecStartPre=, then we can
>> probably use the latter to dynamically generate a per-instance profile
>> from within a unit file itself. This would be ideal, and I think we
>> should try that first.
> That'd be great.
I have good news. It works, here's a PoC:
$ cat /etc/systemd/system/tor.service.d/apparmor.conf
[Service]
ExecStartPre=/bin/sh -c "/bin/sed \
-e 's/profile system_tor/profile
default_system_tor/' \
/etc/apparmor.d/system_tor \
| /sbin/apparmor_parser --skip-cache --replace"
AppArmorProfile=default_system_tor
ReadWriteDirectories=-/proc
# apparmor_parser needs write access there:
ReadWriteDirectories=-/sys/kernel/security/apparmor
I've tested this on 0.2.7.3-rc-1, after making sure sure systemd won't
be using the profile that was already loaded by previous attempts:
/bin/sed -e 's/profile system_tor/profile default_system_tor/' \
/etc/apparmor.d/system_tor \
| sudo /sbin/apparmor_parser --skip-cache --remove
sudo aa-status
And after `sudo service tor restart', aa-status(8) confirms that my
system Tor daemon runs under the 'default_system_tor' profile, that is
necessarily the one we've generated and loaded on-the-fly :)
Now, the ExecStartPre= that generates and loads the profile should be
turned into a no-op when AppArmor is not enabled, e.g. re-using code
we have in /etc/init.d/tor. And it would be nice to move it to
a dedicated executable, instead of being inlined in the systemd unit.
Can you (please) take it over from this point and integrate it, in
your preferred way, with the rest of the packaging?
> Can profiles live outside of /etc/apparmor?
A profile can live wherever we want, *but* it must be loaded into the
kernel (with apparmor_parser(8)) before we can use it; that is, before
systemd calls the aa_change_onexec libapparmor function. That's why
AppArmorProfile= takes a profile name, not a file name. We actually
don't need any file at all, since apparmor_parser can consume stdin,
as demonstrated by the PoC above.
Cheers,
--
intrigeri
