Classic confinement for sFTP Client

store-requests
1

Hello,

We’d like to request Classic confinement for sFTP Client (www.sftpapp.com).

sFTP Client is a File Transfer application for FTP, SFTP, FTPS and Cloud Services, including an SSH Terminal, Port Forwarding and more…

We’ve had several reports from our users unable to access several different parts of their filesystem, for example:

  • Network Mounts
  • ~/.ssh (to select key files for server login)
  • /opt/ (for lampp or other local developer tools)

Our users have their projects in many different areas of their filesystem and the above is some mentioned.

I believe from reading your documentation we’d need the Classic confinement to achieve this, and anyone who’s previously installed would need to run snap refresh sftpclient --classic? or running snap remove sftpclient followed by snap install sftpclient --classic, if we’re able to get this confinement we can update our documentation and app for anyone needing to do this.

Thanks in advance and we’re looking forward to hearing from you, if you require any more info from us or have any questions please let us know.

Best regards,
Danny
sFTP App Ltd

2

I’m not familiar enough with network mounts to know what would be necessary/reasonable to make access to these work with strict confinement. What paths are these at?

For this, there is the ssh-keys and ssh-public-keys interfaces which would allow access to these files.

I’m not sure about this one, but perhaps we could have an interface for mounting /opt from the host into the snap’s mount namespace like we do for /etc? Looking at it, we don’t currently allow access through any interface to /opt, and there is nothing in /opt in the core or core18 snap. @jdstrand what do you think?

3

Hello @ijohnson,

Thanks for the quick response here!

The network mounts is nothing specific (user specified), when a user specifies a local directory to use within our app to perform (local - remote / remote - local) transfers they are presented with the filesystem directory selection, this does not seem to allow our users to select a network path for projects or other data users need to transfer. We’re not the typical FTP/FTPS/SFTP file transfer client, we also provide connections to cloud services too (i.e. Amazon S3, Dropbox, Backblaze B2, Google Cloud Storage, etc etc).

I suppose the use of ssh-keys / ssh-public-keys interfaces would resolve this specific issue, although i’m sure wont be necessary if we had the Classic confinement.

The /opt directory is one example of many root based directories (or non home based directories), another example would /backup to backup data to their remote servers / services, to find other examples i’d have to go through many support tickets / emails to find these, although my point is many of our users have reported issues with accessing non-home based directories.

Really hoping we can get these issues resolved for our users soon.

Best regards,
Danny
sFTP App Ltd

4

It would be useful if you could compile a list of commonly requested directories, because from my experience /home or /media is usually enough for most use cases and so if there are common use cases for other directories we would like to understand them so that eventually we could attempt to craft strict interfaces allowing such accesses.

Additionally, there is an open PR (see https://github.com/snapcore/snapd/pull/6436) which hopefully will eventually add a system-backup interface which would allow read-only access to any directory on the system (other than /dev, /sys, and /proc) which sounds like it would partially solve your use case.

Not sure what to do about the network mounts access, sounds like it could be a GUI bug with the file chooser not searching all paths properly or it could be something else entirely.

5

We have thousands of emails so would be difficult to combine all of these from our customers, we can only provide what we’ve already said in the thread above:

  • /opt/*
  • /home/[user]/ (no issues with this directory apart from some sub directories in local having permission errors)
  • /backup
  • ~/.ssh
  • /var/* (usually www / html folders within this path)

We’ll take a look at Electron and see if theres any known issues there for network mounts, it could be us needing to update our version or reporting an issues to Electron for this.

.
We have a few users asking for updates on this, how soon could we get a classic confinement?

Let us know if theres anything else you need to know.

6

@jdstrand could you take a look at this when you get a chance?

7

The requirements for classic are understood. The application needs wide access to the host filesystem for transferring files.

@sftpclient - does your application require only read/write access to files or does it need execute permissions? Do users typically run this as root or non-root?

8

Hello @jdstrand,

We’re planning to allow users to open files in their default (third party) application, i believe this is achieved using Electrons exec method, example below shows a command we’ll run to find third party apps:

exec('find /Applications ~/Applications -iname *.app', (err, stdout, stderr) => {});

Theres a similar command to open a temp file in the application but don’t currently have that to hand.

If Electrons exec doesn’t require root i can’t imagine us needing root level permission for executing anything.

Best regards,
Danny
sFTP App Ltd

9

@sftpclient - thanks. Non-root access makes it easier to consider for classic. As mentioned before, the requirements are understood.

@advocacy - can someone perform the vetting?

10

@jdstrand @advocacy is there any update on the Classic Confinement?

Thanks in advanced!

11

I see that sftpclient has been published in the store for sometime as a confined snap. There is not an automated way to switch users of a confined snap to a classic snap, so that should also be considered.

Would the use of home-all, personal-files (for ~/.ssh), removable-media, and upcoming system-backup interfaces not be sufficient?

12

@Wimpress from the discussion above, this wouldn’t be sufficient enough :frowning_face: in relation to the app going to classic confinement we can add a dialog box on a new release to let users know how to re-install the app for full access.

@jdstrand @advocacy is there any update on the Classic Confinement yet?

Thanks in advanced!

13

@sftpclient from my perpsective as a reviewer, I would like you to please respond to @Wimpress’s suggestion above about the use of home-all, personal-files etc - can you please comment on whether this would be sufficient?

14

@alexmurray My comment above already states this wouldn’t be sufficient enough.

Please see the comment below for reference why this is: (posted 20 days ago)

15

I believe removable-media covers this requirement.

Read-only access to these locations can be (should be able to be) achieved with the system-backup interface.

These should be covered for read-only access by the system-backup interface.

All non-dot-prefixed files and directories in /home/* are accessible for both read and write using the home interface.

There are two interfaces that cover cryptographic keys files in ~/.ssh, namely ssh-keys and ssh-public-keys. It is possible to request usage of personal-files to access other files in this directory.

You can open files in other applications using xdg-open and ensuring the files are in a readable location such as /home/*/Documents or /media/*/*/ (In strict confinement /tmp is local to the snap and not shared with other applications or snaps) This will not require any scanning for applications in the manner you suggest you are doing with find, because the default handlers of the system will be used when you call xdg-open.

Note, however, that your example command will never find any applications on a linux system, even with classic confinement when packaged as a snap, because the linux world generally doesn’t store applications in /Applications nor do we suffix the executable with .app. I hope this helps, as you will need to update this scan regardless of whether you are granted classic confinement or not.

–

Do all the above points cover your use cases? If they don’t please can you elaborate what extra requirements you have, because as far as you have documented them to the @reviewers so far the points appear to cover everything you’ve said your app needs. Of course I may be wrong in my analysis; please help me and the reviewers understand why, if I am.

1 Like
16

@lucyllewy we’ll need both read and write access for these directories (excluding ~/.ssh only read access is needed for this one, unless we allow user to generate keys within our app in a future update) as you can appreciate from the nature of our application both read and write is required.

The command relating to the Electron exec is an example for macOS, we’re haven’t looked further into the development of this yet so we’re unsure what’ll be the Linux equivalent for this.

@lucyllewy jdstrand has asked for someone to perform the vetting, does this not already mean we’ve be given permission to get the Classic Confinement??? It seems we’re being asked additional questions which have already been explained in this thread, and this seems to be looping now, or being delayed on the same reasons… i thought the requirements for the Classic Confinement were already understood…?

We appreciate you guys wanting to sandbox every app, but this isn’t going to be the case for some apps.

This discussion has also gone on for over a month now, and we’ve had to issue multiple refunds due to the restricted use of our app…

17

@jdstrand as part of the security team has a right to veto the vetting, his comment indicates that he does not veto this request … granting the permission via vetting and voting is still a matter of the @advocacy team in the end …

18

@jdstrand vetting done, +1.

@sftpclient Apologies for the delay here. There is a small fly in the ointment which @Wimpress alluded to, let me explain.

When a user installs a snap, they have an expectation of automatic updates when the developer publishes new releases. If the user installs a strictly confined snap, they can get updates delivered which are also strictly confined. If the user installs a classic snap however, they must indicate they understand the risk, but appending --classic on the snap install line. They too will receive automatic updates.

The issue is when a snap moves from being strict to being classic confined. There’s a gap in our functionality here. Users who installed the strictly confined snap will never have seen the warnings related to classic confinement and as such will never receive the new revision of the application which has migrated to classic.

There are workarounds forward here.
Before we update the store to mark your snap as classic and before you build and publish a classic confined snap, you publish a strict version which incorporates some kind of warning to users that the next update will be classic, and they will have to do the following:

snap remove sftpclient
then
snap install sftpclient --classic --candidate

The popup could be done as a zenity dialog, outside the actual code base of your application, which informs the users who launch your strict application. Here is an example. This would need to be done, as I said, before you publish the classic build in stable. So publish the classic build in the candidate channel.

Alternatively, you could just update your documentation, and those people who are affected by the strict confinement limitations can just be told the manual steps to do. This is the low-impact way forward.

What you’ll end up with is some users wedged on the old strictly-confined revision however. Those will be users who haven’t read the documentation, or users who haven’t launched the application for a while, and as such haven’t seen the popup (assuming you build that into it).

19

@reviewers - please note that classic confinement does not use a voting process. It does require that the requirements are gathered and reviewed by the security team and/or architect. Once the requirements are understood, it is considered ‘approved’ and vetting is requested (though the approval may be overturned by an architect or paused for more discussion).

@sftpclient - it seems what happened here was I understood the technical reasons for classic (since there was a recent similar request), asked for vetting, but then a vetting reviewer (@Wimpress) paused the process for more discussion (which is fine according to the process, if confusing for you this time as the requester; I apologize). He makes an excellent point which is why we have at least two people involved when reviewing classic requests.

@sftpclient - @Wimpress and @popey make excellent points regarding existing users moving from strict to classic. Can you comment on how you will address this concern with your users?

20

@jdstrand as we suggested above we’ll create a dialog box in our app to let our users know how to switch across, and update our documentation on our help site.

Is it safe to say we are going classic confinement now? if so, we can get a release out on snap with a dialog stating that our next release will be a classic release (ideally don’t want to be stating this now to our users if this isn’t the case… if you see what i mean…we’ll only end up getting our users hope up who have been waiting for this).

We’ll also update our app to state what version / release in snap will be available under classic confinement within our documentation at help.sftpapp.com.

If this is all good to go, i’m guessing we’ll update our documentation, get the dialog added into the launch of our app, then report back here? then you guys will change our app to be classic confinement, we then release to candidate, then i’m guessing after a little while we then release to stable…?