Owwatcher auto-connection [Was: Request for classic confinement of owwatcher]

owwatcher needs to be able to read arbitrary locations on the filesystem (particularly /tmp). owwatcher can likely just use the system-backup interface once it becomes available, but must be classic until then.

Note that the snap already has access to /tmp, but /tmp within the the snap’s runtime is snap-specific and not /tmp from the system (but the host’s /tmp is available in /var/lib/snapd/hostfs/tmp).

What does this snap do and what specific accesses are required? Directory access? File access? All access?

What does this snap do and what specific accesses are required? Directory access? File access? All access?

This snap uses inotify to monitor a user-specified directory (usually /tmp) for the appearance of world writable files or directories. This is useful for identifying potential symlink race or TOCTOU vulnerabilities. It needs read-only file and directory access.

(but the host’s /tmp is available in /var/lib/snapd/hostfs/tmp)

While owwatcher can watch any directory, in practice it will likely only be used to monitor /tmp and/or the directory specified by a user’s $TMPDIR environment variable. If /tmp is available in /var/lib/snapd/hostfs/tmp, it may be sufficient to use the ‘home’ interface and read the host’s /tmp without being a classic snap. However, the documentation for the ‘home’ interface says it “allows access to non-hidden files”. I’m assuming that “hidden files” in means “files begining with a ‘.’ character” Applications might create hidden files in $TMPDIR/, in which case the ‘home’ interface is insufficient.

Sorry, I wasn’t clear. /var/lib/snapd/hostfs is available in the runtime environment, but as of today, not via any interfaces. Curious if you add /**/ r, to the policy in /var/lib/snapd/apparmor/profiles/snap.owwatcher.owwatcher if you have the necessary access?

Adding that rule to the apparmor policy allows owwatcher to read /var/lib/snapd/hostfs/tmp, but it can’t recursively read all of the files in /tmp. For example, there’s a directory owned by my user with 700 permissions and the snap is unable to read into that directory, even when run as sudo owwatcher

We discussed this on irc and found that classic confinement is not required when using:

plugs:
  hostfs-tmp:
    interface: system-files
    read:
    - /var/lib/snapd/hostfs/tmp

apps:
  owwatcher:
    plugs:
    - hostfs-tmp
    - log-observe

(log-observe is needed since it grants dac_override which is needed by owwatcher to watch files with non-root ownership and only owner permissions under sudo).

This is an unusual use of system-files but avoids classic. For now, this seems reasonable until there are more users that need access to hostfs; if/when that happens, we can consider a dedicated interface.

@msalvatore - are you wanting to change this request for classic to a request for using system-files with auto-connect for it and log-observe?

@msalvatore - are you wanting to change this request for classic to a request for using system-files with auto-connect for it and log-observe?

@jdstrand - If you absolutely veto it as a classic snap, then yes. However, I have few reservations.

  1. It seems like a misuse of the interface to be using ‘log-observe’ to basically work around a confinement limitation that has nothing to do with observing logs.

  2. While, in practice, owwatcher will be used mostly to watch /tmp, it may be used to monitor other directories as well. I’d prefer to define the plug to read /var/lib/snapd/hostfs instead of /var/lib/snapd/hostfs/tmp.

  3. Since neither system-files nor log-observe are autoconnected, it now takes 3 commands to install this tool. It’s not a huge deal, but is there any way to simplify the installation when using these interfaces?

  4. It’s somewhat cumbersome for users to need to specify ‘/var/lib/snapd/hostfs/’ as part of the path that they want to monitor. To work around this, I can have the application try to determine whether or not it’s snapped and automatically prefix that path. Is there an official way for an application to determine whether or not it’s a snap? Currently it checks for the existence of the $SNAP_DATA environment variable to determine where it should put its log. Of course, the 3rd party inotify library doesn’t make this determination, which could lead to some confusion in the debug logging since the inotify won’t strip away the /var/lib/snapd/hostfs prefix in its debug logging output.

In summary, I don’t think the current solution using system-files and log-observe is ideal, but if it’s the only way, then it is what it is. If some of my concerns can be easily addressed, so much the better.

Checking environment variables is probably the best way, if you wanted to be really paranoid you could check if the file /meta/snap.yaml exists (your snap can’t read the file, but you can still see if the file exists with something like test -f /meta/snap.yaml or ls /meta/snap.yaml). That file should only exist if you are running inside strict snap confinement, as it is the snap.yaml for the base snap your snap declares.

@msalvatore this is waiting on your response to @ijohnson’s suggestion about checking if running inside a snap environment or not - can you please respond regarding this since to my reading granting auto-connect for system-files and log-observe plus updating the snap to automatically use /var/lib/snapd/hostfs when it detects it is a snap would be sufficient for owwatcher to be a strict mode snap.

@alexmurray, yes, I think doing all of these things is sufficient.

Should I publish an updated snap?

@alexmurray, @jdstrand: I’ve pushed an updated snap that uses the interfaces we discussed.

Thank you for updating the snap. @msalvatore, your use of hostfs grants very privileged access to the system since it can, for example, read anything from /dev, /sys or /proc. Since this request came in, a new system-backup interface came in which will be available in 2.43 and is slightly less privileged in that it doesn’t allow access to these directories (however, system-backup is still privileged).

@msalvatore - does your snap require complete access to /dev, /sys and /proc outside what is normally provided by the interfaces? If not, please update to use system-backup instead. If not, please detail why. Once you’ve answered this, we can vote on the updated request.

@jdstrand, It does not need access to /dev, /sys, or /proc. I’ve pushed an updated snap that uses the system-backup interface.

Thanks!

+1 to auto-connect system-backup and log-observe. While this software is not backup software, it requires the same hostfs access that is provided by the system-backup interface which provides somewhat less access than all of hostfs.

@reviewers - can others vote on this?

+1, the requested interfaces seem well-constrained for what the snap intends to do, and seem better than requiring classic.

  • Daniel

+1 from me too to auto-connect system-backup and log-observe

3 votes for, 0 against for auto-connect of system-backup and log-observe. This is now live.