~mvo/snappy/snappy-lp1460152-workaround-15.04

Application authors should not have to know about or understand the lowlevel

implementation details on how security policy is enforced. Instead, security

policy is typically defined by declaring a security template to use and any

additional security caps to extend the policy provided by the template. If

origin from the store if applicable -- only snaps of `type: app` (the

default) use an origin to compose the `APP_ID`), the

`<pkgname>.<origin>_<appname>_<version>`. For example, if this is in

and the app was uploaded to the `myorigin` origin in the store, then the

app launcher.

 

Under the hood, the launcher:

 

* sets up various environment variables (eg, `SNAP_APP_ARCH`,

* changes directory to `SNAP_APP_PATH` (the install directory)

* sets up a device cgroup with default devices (eg, /dev/null, /dev/urandom,

  etc) and any devices which are assigned to this app via OEM snaps or

  `snappy hw-assign` (eg, `snappy hw-assign foo.myorigin /dev/bar`).

* sets up the seccomp filter

* executes the app under an AppArmor profile under a default nice value

 

The launcher is used when launching both services and CLI binaries. The

security policy and launcher enforce application isolation as per the snappy

FHS.

 

This combination of restrictive AppArmor profiles (which mediate file access,

application execution, Linux capabilities(7), mount, ptrace, IPC, signals,

coarse-grained networking), clearly defined application-specific filesystem

areas, whitelist syscall filtering via seccomp and device cgroups provides for

strong application confinement and isolation (see below for future work).

    * AppArmor access is deny by default and apps are restricted to

      their app-specific directories, libraries, etc (enforcing ro,

      rw, etc).  Additional access beyond what is allowed by the

      declared `security-template` is declared via this option

    * seccomp is deny by default. Enough safe syscalls are allowed so

      that apps using the declared `security-template` should

      work. Additional access beyond what is allowed by the

      `security-template` is declared via this option

    * `apparmor: path/to/security.override`

    * `seccomp: path/to/filter.override`

    * `apparmor: path/to/profile`

    * `seccomp: path/to/filter`

If this package is uploaded to the store in the `myorigin` origin, then:

## Debugging

To check to see if you have any denials:

 

    $ sudo grep audit /var/log/syslog

 

An AppArmor denial will look something like:

 

    audit: type=1400 audit(1431384420.408:319): apparmor="DENIED" operation="mkdir" profile="foo_bar_0.1" name="/var/lib/foo" pid=637 comm="bar" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

 

If there are no AppArmor denials, AppArmor isn't blocking the app.

 

A seccomp denial will look something like:

 

    audit: type=1326 audit(1430766107.122:16): auid=1000 uid=1000 gid=1000 ses=15 pid=1491 comm="env" exe="/bin/bash" sig=31 arch=40000028 syscall=983045 compat=0 ip=0xb6fb0bd6 code=0x0

 

The `syscall=983045` can be resolved with the `scmp_sys_resolver` command:

 

    $ scmp_sys_resolver 983045

    set_tls

 

If there are no seccomp denials, seccomp isn't blocking the app.

 

For more information, please see

[debugging](https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Debugging).

 

    * utilize syscall argument filtering

    * setup additional cgroups (tag network traffic, memory)

    * setup iptables using cgroup tags (for internal app access)

    * drop privileges to uid of service

* fine-grained network mediation via AppArmor

    * `names`: (optional) list of abstract socket names

      (`<name>_<binaryname>` is prepended)

    * `allowed-clients`: `<name>.<origin>` or

     `<name>.<origin>_<binaryname>` (ie, omit version and

     `binaryname` to allow all from snap `<name>.<origin>` or omit

     version to allow only `binaryname` from snap `<name>`)