[08:47] <wsnipex> hi
[08:48] <wsnipex> how does one specify apparmor/seccomp policies after old-security was removed in snap?
[09:07] <wsnipex> sergiusens, ping
[11:28] <blackout24> jjohansen1, I made a package from your git branch. However I still get an execv error after loading the aa profile into the kernel. I stepped through ubuntu-core-launcher with gdb and it loads all the seccomp rules and aa profiles and after around 16000 steps fails in main at:
[11:28] <blackout24> 585		execv(binary, (char *const *)&argv[NR_ARGS]);
[11:29] <blackout24> (gdb) print binary: $6 = 0x7ffdcb8d9508 "/snap/ubuntu-calculator-app/5/command-calculator.wrapper"
[11:29] <jjohansen1> blackout24: any messages in dmesg?
[11:29] <blackout24> I don't understand why I get "execv failed: No such file or directory", when this file is present in that location
[11:32] <blackout24> jjohansen1, http://pastebin.com/raw/4PH7aRxH That must have been from when I apparmor_parser -r'ed the profile
[11:32] <blackout24> before that it wasn't loaded according to apparmor_status
[11:32] <blackout24> now I have
[11:33] <blackout24> 1 profiles are loaded. 1 profiles are in enforce mode. snap.ubuntu-calculator-app.calculator
[11:34] <jjohansen1> blackout24: can you paste the output of
[11:34] <jjohansen1>   sudo cat /sys/kernel/security/apparmor/profiles
[11:34] <blackout24> snap.ubuntu-calculator-app.calculator (enforce)
[11:34] <blackout24> that's the whole output
[11:35] <blackout24> I don't think that it's a problem with the apparmor side, since it fails at the excecv part in main.c in ubuntu-core-launcher, which seems to be past the whole profile loading stuff from stepping through it
[11:35] <jjohansen1> so what I am seeing from the log is snappy is doing the change_onexec to snap.ubuntu-calculator-app.calculator before the profile is loaded
[11:35] <blackout24> ahh ok
[11:35] <jjohansen1> notice the DENIED entry comes before the STATUS profile_load
[11:36] <jjohansen1> change_onexec is returning -2
[11:36] <jjohansen1> which is enoent
[11:37] <blackout24> I used the v4.5-aa3.5-beta1 branch from your git tree. Just cloned it and compiled it.
[11:37] <jjohansen1> so that may be why you are seeing an enoent
[11:37] <jjohansen1> blackout24: right, this isn't a kernel problem
[11:38] <jjohansen1> I have no idea why that change_onexec is coming before the profile is loaded
[11:38] <jjohansen1> but the kernel won't find the profile is it isn't loaded
[11:39] <blackout24> There was a problem with security/apparmor/include/domain.h I had to change line 18 into #include "label.h" (was #include "include/lable.h"), but the lable.h is in the same dir.
[11:39] <blackout24> Otherwise the kernel wouldn't compile
[11:41] <jjohansen1> blackout24: doh, we do have a patch for that, I must have dropped it from the branch
[11:41] <jjohansen1> I'll make sure to get that cherry-picked
[11:59] <blackout24> jjohansen1, I think I managed to get a little bit further with getting snappy to run on Arch. Maybe. ubuntu-core-launcher has its own profile which I installed to /etc/apparmor.d/usr.bin.ubuntu-core-launcher. However these profiles don't seem to get automatically pickedup so I parsed it manually.
[11:59] <blackout24> Now trying to run the calculator app gives me:
[11:59] <blackout24> /usr/bin/ubuntu-core-launcher: error while loading shared libraries: libapparmor.so.1: cannot open shared object file: Permission denied
[12:00] <blackout24> ubuntu-core-launcher is setuid root on my system just like on 16.04
[12:02] <blackout24> That's the dmesg: http://pastebin.com/raw/jyxDs6Ra
[12:05] <blackout24> brb
[16:03] <blackout24> Mhh one of the biggest problems when trying to get snappy to work on Arch Linux is that apparmor restrictions don't seem to work on symlinks. Ubuntu and Debian still have the libs scattered around /lib /lib64 /usr/lib etc. On Arch and Fedora the first two are just symlinks to /usr/lib and everything is installed there.
[16:05] <blackout24> The usr.bin.ubuntu-core-launcher profile in /etc/apparmor.d for example restricts the access to /lib/@{multiarch}/libapparmor.so* to mr. I deleted the @{multiarch} part since /lib/apparmor.so* and /usr/lib/libapparmor.so* are still the same thing on Arch. I reparsed the profile, but still got access denied for this shared object. Only writing /usr/lib/libapparmor.so* in the profile worked.
[21:14] <zzarr> hello!
[21:15] <zzarr> is it possible to make a snap package that uses the gpu?