How to move from devmode to strict confinement?


#1

Devmode confinement is very easy to work with but trying to make snap work with a strict one is pretty tricky.

As an example I’m bringing an attempt to run tmux/mosh/weechat as a snap package. This github PR describes the problems I’m getting: https://github.com/chrmod/snap-irc/pull/2

At this moment I’m focusing on mosh which happens to complain:

Can't load '/usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so' for module IO: /usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so: failed to map segment from shared object at /usr/lib/x86_64-linux-gnu/perl-base/XSLoader.pm line 70.

but IO.so is present at /snap/irc/current/usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so.

In the same time dmesg reports

[200469.441078] audit: type=1326 audit(1494450866.992:81245): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=19613 comm="weechat" exe="/snap/irc/x1/usr/bin/weechat" sig=31 arch=c000003e syscall=133 compat=0 ip=0x7f8d706cc0fd code=0x0
[200822.035872] audit: type=1400 audit(1494451219.587:81246): apparmor="DENIED" operation="file_mmap" profile="snap.irc.mosh" name="/usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so" pid=26155 comm="perl" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0

Is there a guide that suggests how to progress with strict confinement?


#2

I suggest looking through this: Security policy and sandboxing

Importantly, it will recommend that you install ‘snappy-debug’ which can be used to suggest various things (eg, interfaces to plug, things to change in your snap, etc).

That said, based on your denials, your snap is attempting to:

  • use the mknod syscall (scmp_sys_resolver 133)
  • use /usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so

For the first, this should be resolved in snapd 2.25 where we are using seccomp arg filtering for the mknod syscall to allow creating files, sockets and pipes (but not block or character devices)

For the second, you reference you are expecting your snap to use /snap/irc/current/usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so, but the denial is for /usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so. This indicates a problem with your snap not finding the proper IO.so. You may need to set PERL5LIB appropriately or otherwise adjust your snap so @INC will find your module. A snapcraft developer may be able to help further.

Interestingly, I expected /usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so to be allowed by the apparmor policy via the /etc/apparmor.d/abstractions/perl include file. It has:

/usr/lib/@{multiarch}/perl{,5}/**            r,
/usr/lib/@{multiarch}/perl{,5}/[0-9]*/**.so* mr,

but /usr/lib/x86_64-linux-gnu/perl-base/auto/IO/IO.so doesn’t match that. I’ll get that fixed.


#3

Moved the document linked by @jdstrand above into the forum:


#4

I’m getting syscall=133 (mknod) error under snap version 2.26.9.
Below is the syslog snapshot.

Jul 26 15:55:38 dev2 audit[25102]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 pid=25102 comm="bacApp" exe="/snap/et-gw/x11/bin/bacApp" sig=31 arch=c000003e syscall=133 compat=0 ip=0x7f7f9b307cad code=0x0
Jul 26 15:55:38 dev2 systemd[1]: snap.et-gw.bacApp.service: Main process exited, code=killed, status=31/SYS
Jul 26 15:55:38 dev2 kernel: audit: type=1326 audit(1501102538.990:247983): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=25102 comm="bacApp" exe="/snap/et-gw/x11/bin/bacApp" sig=31 arch=c000003e syscall=133 compat=0 ip=0x7f7f9b307cad code=0x0
Jul 26 15:55:39 dev2 /usr/bin/snap[25115]: cmd.go:118: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
Jul 26 15:55:39 dev2 systemd[1]: snap.et-gw.bacApp.service: Unit entered failed state.
Jul 26 15:55:39 dev2 systemd[1]: snap.et-gw.bacApp.service: Failed with result 'signal'.
Jul 26 15:55:39 dev2 systemd[1]: snap.et-gw.bacApp.service: Service hold-off time over, scheduling restart.
Jul 26 15:55:39 dev2 systemd[1]: Stopped Service for snap application et-gw.bacApp.

Is there a way I can fix it?


#5

This is actually fixed in trunk (and therefore the upcoming snapd 2.27) for S_IFREG, S_IFIFO and S_IFSOCK in the default template. If your snap is trying to create block or character devices, we’d need to gather specifics on the devices in question and determine the best path forward.


#6

Thanks jdstrand.

Do you know when is snapd 2.27 release expected?


#7

I don’t, no (I’m not on the snappy release team). Perhaps @mvo can comment when 2.27 will be released.


#8

If we managed to address all pending issues in time, next Monday.


#9

Thats a good news. Thanks @niemeyer


#10

Just encountered this today, is this issue fixed?