Classic confinement for sFTP Client

[sftpclient]

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

[jdstrand]

@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?

[sftpclient]

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

Thanks in advanced!

[Wimpress]

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?

[sftpclient]

@Wimpress from the discussion above, this wouldn’t be sufficient enough 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!

[alexmurray]

@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?

[sftpclient]

@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)

Classic confinement for sFTP Client

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 report…

[lucyllewy]

@sftpclient

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 believe removable-media covers this requirement.

@sftpclient

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

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

@sftpclient

• /opt/*
• /backup
• /var/*

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

@sftpclient

/home/[user]/

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

@sftpclient

~/.ssh

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.

@sftpclient

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) => {});

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.

[sftpclient]

@sftpclient

• /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)

@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.

@lucyllewy

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.

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.

@jdstrand

@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?

@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…

[ogra]

@sftpclient

jdstrand has asked for someone to perform the vetting, does this not already mean we’ve be given permission to get the Classic Confinement???

@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 …

[popey]

@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).

[jdstrand]

@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?

[sftpclient]

@sftpclient

@Wimpress from the discussion above, this wouldn’t be sufficient enough 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 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…?

[alexmurray]

It would appear @sftpclient has a plan to manage helping transition users to classic confinement - so this looks good to go from a requirements and user experience point of view. @advocacy - could you please perform the required vetting?

[sftpclient]

@jdstrand Is it safe to say we are going classic confinement now?

Once confirmed we can update our app with the first step.

[jdstrand]

@advocacy - can you please perform the vetting?

@sftpclient - yes, classic will by allowed once the @advocacy team performs due diligence.

[popey]

Vetting done, +1 from my side.

[alexmurray]

Granted, this is now live for sftpclient.

[sftpclient]

@jdstrand @popey @alexmurray thanks!

Can i ask what our next steps should be?

Apologies for the delayed response, i’ve been away for a couple weeks.

[alexmurray]

@sftpclient - the sftpclient now has the permission granted by the store to be a classic snap - so any future uploads which specify confinement: classic will be automatically approved - so my understanding is you can now migrate your users to this new classic confined version of the snap as you discussed earlier.