Classic confinement for bootstack-ops snap

store
9

That works for me. I can even write the interface and get it up quickly. @xavpaice, if you are agreeable, please reaffirm that it is only read-only access to ~/.local/share/juju you are interested in. Please consider future cases where you may want read-only access to other things juju (and what those paths are) so we can decide on juju-client-observe vs juju-observe.

10

Before reading this larger response, please see my question about ‘juju-observe/juju-client-observe’ since that is the immediate path forward. Answering your questions here for completeness.

Note that today classic snaps cannot use ‘plugs’ for various reasons. We could certainly lift that for the content interface (ie, we only add apparmor policy/etc if confinement != classic), but this would require some work to detangle applying various security backends except mount when using classic confinement.

It’s also interesting to think about exporting per-user content via the content interface. Normally we export content from the SNAP, SNAP_COMMON or SNAP_DATA. Yours would be the first use case for this (and likely have to build on the per-user work that was recently done for portals).

Gustavo mentioned why we don’t allow access to dot files and I’ll expand on that. It is important to note that traditional desktops have the concept of a trusted session where each user runs a login session and anything that the user runs is considered trusted by the user. Snaps change that and snaps are considered untrusted by the user session and from each other so we don’t allow snaps to access each other or anything outside the snap by default. We then have interfaces that expand that access in controlled ways. The home interface is a so-called transitional interface (because the access it grants is so broad) to enable existing software to access non-hidden data. We could allow accessing hidden data, but then we’d expose potentially very sensitive data to all snaps using the home interface-- eg, ssh and gpg keys (it is natural to then say “well, just block those” but a blacklist approach is never complete-- we might add ssh and gpg, but forget .fetchmailrc, for example). It is important to also keep in mind the dot directories are used by the user’s trusted session applications that typically come from debs/etc (ie, not snaps) and these files are often incompatible with snaps that have different versions of the same software installed or use different underlying libs (eg, gtk). If the snap had read or write access to arbitrary dot files, then the snap may not function correctly (eg, since the dot files use an old format) or the snap might break the user’s session (eg, since the snap migrates from the old format to the new and now the user session is broken; I’ve personally seen someone’s desktop session get completed hosed because he (on his own, not because it was advised!) bind mounted his home into the snap and the snap made a bunch of incompatible changes).

Finally, it was my understanding that the juju snap could move to strict confinement after we introduced one of the ssh-keys or gpg-keys interfaces (I can’t remember which otoh), and Nicholas said he’d move juju to strict confinement. I realize he has moved on, but if there are still things keeping juju classic, please review those and perhaps introduce a new topic so we can work through any remaining issues.

Hope this clarifies some things!

11

@jdstrand, @niemeyer, yes it’s read-only access to ~/.local/share/juju that I’m looking for - no write required. Having a juju-client-observe interface would be absolutely perfect for my use case, I hadn’t even considered that adding an interface might be an option. I might need a little advice on how to access the directory since $HOME is specific to the snap, but there’s an env var I can use for juju client config which can remap me back to the right place. Currently, if I add JUJU_DATA=${HOME}/.local/share/juju’ to the env from which I call the snap (i.e. before $HOME is remapped), I seem to get the right result. If there’s a way to trigger the interface to avoid having to edit .bashrc that would be ideal, but not essential.

We will also want access to the juju binary, which is in the path via /snap/bin but might also be from a .deb, depending on the history of the machine.

Thanks so much for the detailed information here, it’s something I think a number of folks might find useful.

It turns out there were a number of items that meant the Juju client snap needed classic, from the README in the repo:

Needed for confinement

To enable strict mode, the following bugs need to be resolved, and the snap updated accordingly.

12

I can write this. I’ve added it to my todo and should have something up for review later today.

13

You can always call ‘getent’ to get the home for the user as opposed to the home for the snap. Eg: getent passwd $UID | cut -d ':' -f 6.

14

“Missing support for abstract unix sockets (https://bugs.launchpad.net/snappy/+bug/1604967 )”
There is an open question on this in the bug. The last time I talked to Nicholas I was under the impression this was no longer needed. Also note new support for socket, socket-mode and listen stream (Snapcraft.yaml reference) that may help you in this area

“Needs SSH interface (https://bugs.launchpad.net/snappy/+bug/1606574 )”
This should be DONE (we now have both ssh-keys and ssh-publis-keys interfaces)

“Bash completion doesn’t work (https://launchpad.net/bugs/1612303 )”
This should be DONE. You might try looking into @chipaca’s excellent bash completion work: Tab completion for snaps

“Juju plugin support (https://bugs.launchpad.net/juju/+bug/1628538 )”
This doesn’t seem to be a snapd deficiency (please correct if I’m wrong). We now have a content interface (The content interface) that should allow the juju snap to ‘slot’ a read/write area and for plugins to ‘plug’ this slot and write data to it. How you organize it, do registration, etc is completely up to you

Can you verify the above and confirm if anything else is still needed?

15

https://github.com/snapcore/snapd/pull/5229

16

FYI, juju-client-observe is merged into master and the upcoming 2.33.

1 Like
17

The Juju plugin protocol requires the ‘juju’ command line tool to execute arbitrary programs on $PATH that begin with ‘juju-’. It seems incompatible with confined snaps, and changing it would technically be a backwards incompatible change and shouldn’t be done until Juju 3.0 (to eg. require plugins to be installed in /snap somewhere, or be distributed as snaps that are plugged into the Juju snap)

18

I’m not familiar with the juju plugin protocol (maybe @niemeyer should weigh in on design for strictly confined juju), but it seems like the juju snap could provide a read-only slot that plugin snaps could consume which allows use of the ‘juju’ command (additional interfaces might need to be developed) and the juju snap could provide a read/write slot that plugin snaps could consume to write to. The juju snap is updated to add the read/write area to its PATH. Non-snap juju plugins write to wherever the juju command expects to find them (again, another interface might be needed for the juju snap to have this access, perhaps ‘juju-support’).

I am certainly missing details and don’t have the full picture… but it seems based on my limited understanding that juju could plausibly be strictly confined. @niemeyer - help! :slight_smile:

19

Now that we have the 2.33 released, I tried to use the new interface to hook up the juju client and get confinement working, but when uploading to the store I get the following:

Error while processing...
The store was unable to accept this snap.
  - interface 'juju-client-observe' not found in base declaration
  - interface 'juju-client-observe' not found in base declaration
  - interface 'juju-client-observe' not found in base declaration
  - unknown plugs interface name reference 'juju-client-observe'
  - unknown plugs interface name reference 'juju-client-observe'
  - unknown plugs interface name reference 'juju-client-observe'

Is there something obvious that I’m missing here? I’ve added the following to the snapcraft.yaml:

apps:
  myfabulousapplication:
    command: something
    plugs:
      - all-the-other-plugs
      - juju-client-observe
20

It exists here:

$ snap interfaces :juju-client-observe
Slot                  Plug
:juju-client-observe  -

$ snap version 
snap    2.34
snapd   2.34
series  16
ubuntu  18.04
kernel  4.15.0-24-generic

What is the output of snap version?

21

My build box is 2.33.1, as is the client I’m testing with, and I do see the interface present everywhere. However, it’s when I upload to the store that I get errors, building is OK as is making the connection on install.

22

This is a bug in the review-tools. I’ll fix that. Please continue to upload to the store in strict and request a manual review and I’ll review the snap as needed until the fix is in production.

23

This is updated in master and on its way to production.

24

I’ve had no success at getting the snap confined - mostly because I need access to a Juju binary even if we have the interface to get the client config, and short of including that binary via a deb inside the snap, or a complete compile of the juju client, I’m stuck. This is effectively along the same lines as the Juju plugins that stub mentions. Any chance of a reconsideration for classic confinement?

I’ll add that this repo is a slowly growing list of ops tools that will use the Maas CLI, plus Juju client.

25

@niemeyer - what are your thoughts on @xavpaice’s most recent comments?

26

Update: I’ve been asked to remove that particular snap anyway, we’re working on removing the tooling and putting it where it belongs in the product itself, making a separate snap obsolete. I’ve marked the snap private now, and would like some help if possible to delete it from the store.

27

@xavpaice The store team can help with that, but can you please open an independent thread for this? This issue has been marked solved, which probably will detour eyes away from it.

28

@xavpaice hi! Snaps aren’t usually deleted; if you want it to be completely unfindable/uninstallable, while still keeping the name in case you want to use it in the future, you can close all channels:

snapcraft close bootstack-ops edge beta candidate stable

and of course, keeping it private makes it even more… private :slight_smile:

If, on the other hand, you absolutely want to entirely banish the snap name from existence (which also means you will never, ever again in the history of the universe, be able to publish a snap under the bootstack-ops name, so you’d better be absolutely sure you want this!) we can delete/revoke the name. I think this may be what you want but I wanted to be very clear on the dire consequences of making this decision. If so, in order to keep a separate paper trail, please do as Gustavo suggested and open a new topic asking for the revocation of the snap. I apologize for the extra step, but consider this an “are you really really sure you want to do that?” kind of action to make you pause and consider things.

Cheers,

  • Daniel