On Tue, Jan 27, 2015 at 1:58 PM, Topi Miettinen <toiwo...@gmail.com> wrote: > > Well, I'm no expert on AppArmor policies. This is what I have: > > #include <tunables/global> > > /lib/systemd/systemd-timesyncd {
I am not sure how that would be done, but this needs to handle timesyncd being in /usr/lib/systemd as well as /lib. Also, adding `flags=(complain)` just before the curly brace puts the profile into complain mode by default. > #include <abstractions/nameservice> > > capability setgid, > capability setuid, > capability sys_time, > capability setpcap, > > /etc/ld.so.cache r, > /etc/systemd/timesyncd.conf r, > /lib/systemd/systemd-timesyncd mr, > /lib/x86_64-linux-gnu/libattr.so.* mr, > /lib/x86_64-linux-gnu/libc-*.so mr, > /lib/x86_64-linux-gnu/libcap.so.* mr, > /lib/x86_64-linux-gnu/libm-*.so mr, > /lib/x86_64-linux-gnu/libnsl-*.so mr, > /lib/x86_64-linux-gnu/libpthread-*.so mr, > /lib/x86_64-linux-gnu/libresolv-*.so mr, Use the variable `@{multiarch}` in place of `x86...`. Also, it is probably desirable to add `{,usr/}` between the / and lib in these lines for distros like Arch that have made the /usr merge. > /proc/cmdline r, > /proc/sys/kernel/random/boot_id r, @{PROC} rather than /proc, so `@{PROC/cmdline r,`. > /run/systemd/netif/state r, I have seen compatibility for pre-/run distros (i.e. adding `{,var/}` before the run but after the slash), but probably not relevant for a systemd daemon. > /var/lib/systemd/clock w, > } Then post to appar...@lists.ubuntu.com asking for a review. Lennart: if you really want to test the profile, you just need to spin up an OpenSuSE, Ubuntu, or Debian VM (on debian you need to install and enable apparmor, which takes a short while). Cheers, -- Cameron Norman _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel