/dev/pts/# denial when running snap-confine under sshd configured for pam-apparmor

[Jamie Strandboge]

[Impact]

When snap-confine itself is invoked over an SSH connection, with sshd using non-standard Apparmor confinement with pam-apparmor, snap-confine would fail.

This change was introduced by a member of the security team who is using this non-standard configuration.

[Test Case]

Ensure that the policy compiles and does not regress using snaps over ssh. Eg:
$ ssh foo
$ sudo snap install hello-world
$ hello-world

[Regression Potential]

* Minimal, snap-confine has a more permissive apparmor profile that allows it to access /dev/pts/[0-9]* for both reading and writing.

[Other Info]

* This bug is a part of a major SRU that brings snap-confine in Ubuntu 16.04 in line with the current upstream release 1.0.41.

* snap-confine is technically an integral part of snapd which has an SRU exception and is allowed to introduce new features and take advantage of accelerated procedure. For more information see https://wiki.ubuntu.com/SnapdUpdates

== # Pre-SRU bug description follows # ==

Logging into an Ubuntu 16.04 machine that has a confined sshd and running 'hello-world', I see this denial:

kernel: [180734.692698] audit: type=1400 audit(1473365455.056:98): apparmor="DENIED" operation="file_inherit" profile="/usr/lib/snapd/snap-confine" name="/dev/pts/2" pid=28375 comm="ubuntu-core-lau" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000

What is happening is that the fd is being remediated since it is not coming from an unconfined process. Fix is:

    /dev/pts/[0-9]* rw,

[Leo Arias (elopio)]

I ran the snap-confine test in an up-to-date xenial classic kvm, after enabling proposed and upgrading to snap-confine to 0.43.

I got no errors, looks good.