Possible security issue? strict confinement snap can access home directory

I am very new to snaps and just finished this tutorial on creating your first snap -https://tutorials.ubuntu.com/tutorial/create-your-first-snap#0

So, I installed my hello snap on my Ubuntu 16.04 LTS machine with strict confinement, and both the hello and bash commands work. However, inside of the bash shell that the command starts, I can read and write to files in my home directory, even hidden ones like .bashrc. Is this supposed to happen? and if it is, isn’t it somewhat of a security risk?

Also, I double checked and the snap is not connected to the home interface. I am trying to learn more about snaps and how they work, so if anyone could explain to me how this works and why it happens I would be grateful.

That example uses confinement: devmode which is effectively unconfined for debugging purposes. devmode snaps cannot be published in the stable channel in the store.

Here’s a great blog post which covers this in some detail. https://snapcraft.io/blog/snapcraft-confinement-interfaces

Thank you for the quick reply, but as I said before I finished the entire tutorial and I changed the example snap’s confinement to strict in the yaml file and then rebuilt the snap, and it is still allowing me access to certain nonhidden and hidden files in my home directory.

Did you specify --devmode when you ran snap install with your snap? Did you also re-run snap install once you’d rebuilt the snap with confinement: strict in the yaml?

Can you please post the output of snap version?

Accessing non-hidden files is expected if you specify the home interface. As well as snap info (snapname), also snap connections (snapname) and let us know the path you use to launch the binary, would be helpful.

I did not specify --devmode when I installed it, and yes this was after I changed the yaml. Here is the output of snap version:

snap    2.39.2
snapd   2.39.2
series  16
ubuntu  16.04
kernel  4.4.157-0404157-generic

I did not specify the home interface. Here is the output of snap info hello-fritz:

name:      hello-fritz
summary:   GNU Hello, the "hello world" snap
publisher: Fritz Grunert (fgrunert)
license:   unset
description: |
  GNU Hello prints a friendly greeting.
  - hello-fritz.bash
  - hello-fritz.hello
snap-id:      NnFWljwJeiQU7UiR4N7dVNZPsrSO2dmr
tracking:     stable
refresh-date: today at 17:06 EDT
  stable:    2.10 2019-06-26 (1) 3MB -
  candidate: 2.10 2019-06-26 (1) 3MB -
  beta:      ↑                       
  edge:      ↑                       
installed:   2.10            (1) 3MB -

Snap connections hello-fritz does not give any output. I am not sure if this is what you mean by the path used to launch the binary, but the output of which hello-fritz.bash is: /snap/bin/hello-fritz.bash

The other unique thing is that my directories when building the snap were not the same as what the tutorial showed. Within hello/ I only had a .snap binary, prime/ and snap/. Also when I changed the name to hello-fritz, a new .snap binary was created (with the hello-fritz name), but within mysnaps/hello/snap. Here is the directory structure of hello/ (with some files removed for brevity, which I can add back if they’re relevant):

β”œβ”€β”€ hello_2.10_amd64.snap
β”œβ”€β”€ prime
β”‚   β”œβ”€β”€ bin
β”‚   β”‚   β”œβ”€β”€ bash
β”‚   β”‚   β”œβ”€β”€ bashbug
β”‚   β”‚   └── hello
β”‚   β”œβ”€β”€ command-bash.wrapper
β”‚   β”œβ”€β”€ command-hello.wrapper
β”‚   β”œβ”€β”€ meta
β”‚   β”‚   β”œβ”€β”€ gui
β”‚   β”‚   └── snap.yaml
β”‚   β”œβ”€β”€ share
β”‚   β”‚   β”œβ”€β”€ doc
β”‚   β”‚   β”‚   └── bash
β”‚   β”‚   β”‚       β”œβ”€β”€ (bunch of bash files
β”‚   β”‚   β”œβ”€β”€ info
β”‚   β”‚   β”‚   β”œβ”€β”€ bash.info
β”‚   β”‚   β”‚   └── hello.info
β”‚   β”‚   β”œβ”€β”€ locale
β”‚   β”‚   β”‚   β”œβ”€β”€ (lots of dir for different languages)
β”‚   β”‚   └── man
β”‚   β”‚       └── man1
β”‚   β”‚           β”œβ”€β”€ (3 files)
β”‚   └── snap
β”‚       └── command-chain
β”‚           └── snapcraft-runner
└── snap
    β”œβ”€β”€ hello-fritz_2.10_amd64.snap
    └── snapcraft.yaml

I don’t know if that last part is relevant but it’s the only odd part about my creation of this snap

I don’t appear to have the same issue you do?

alan@KinkPad-K450:~$ hello-fritz.hello 
Hello, world!
alan@KinkPad-K450:~$ hello-fritz.bash
bash-4.3$ echo $SNAP
bash-4.3$ pwd
bash-4.3$ ls
ls: cannot open directory '.': Permission denied
bash-4.3$ cd $HOME
bash-4.3$ pwd
bash-4.3$ ls
bash-4.3$ touch foo
bash-4.3$ ls
bash-4.3$ cd /home/alan
bash-4.3$ touch foobar
touch: cannot touch 'foobar': Permission denied

this is some non-ubuntu kernel (mainline PPA ? ) which will cause snapd to move to degraded confinement mode AFAIK

1 Like

Can you run snap debug sandbox-features and post the output?

Okay, it seems like you’re right @ogra, although the person who installed ubuntu and the kernel swears that they did nothing to change the kernel from what came with the ubuntu image.

apparmor:             kernel:caps kernel:domain kernel:file kernel:policy kernel:rlimit parser:unsafe 
policy:downgraded support-level:partial
confinement-options:  classic devmode
dbus:                 mediated-bus-access
kmod:                 mediated-modprobe
mount:                freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per- 
snap-updates per-snap-user-profiles stale-base-invalidation
seccomp:              bpf-argument-filtering
udev:                 device-cgroup-v1 tagging

So, yes, the confinement support is downgraded to partial. This was confusing to me because the snap is still strictly confined according to snap info --verbose hello-fritz

Anyway thank you all for your help, but I think this point is now moot for me anyway because I’m going to be switching to Ubuntu 18.04 LTS very soon.

@zyga-snapd (cc @pedronis) - perhaps we can address this confusion as part of your partial enablement work.

I’ve proposed https://github.com/snapcore/snapd/pull/7058 that is related to this topic

1 Like