Classic Confinement for "sdpclient"

Hi Team!

We have debated time and again on choosing the best way(s) to distribute our electron application to Linux customers and Snap has been part of the conversation from get go.

tl;dr

This is a security utility that allows customers to access their applications via a secure tunnel. This means it needs access to starting and stopping processes (stunnel in this case). It will create and install certificates, keys and configuration files in a non-root hidden location in user’s home folder. It will also need the device information since we follow user+device authentication policies. Information like the machine-ID, what (if any) antivirus tools have been installed and other information available through sudo dmidecode.

It is for these reasons I would like to request a classic confinement for sdpclient.

Now I will get into more details and the issues I have faced in snapcraft. Will gladly appreciate your feedback.

  • Stunnel

The electron application does not even recognize that stunnel in installed in the system. And even if it did recognize, I still need to run it in sudo mode which is not supported in strict confinement.

$ sudo stunnel name.conf

And then to stop stunnel I need to run either

$sudo kill -9 pidfile
OR
$sudo fuser -v -k port/tcp

Both will need privileged access.

Well, maybe if stunnel is also another snap application it can recognize?? I googled and to my excitement I learned that a snap exists https://snapcraft.io/stunnel5

But after some testing I honestly did not understand the point of the stunnel snap. First of all it is not a classic confinement. Which means it does not recognize the configuration files in my system without --devmode. Secondly, it has to be run as sudo.

$sudo snap install stunnel5 --devmode
$sudo stunnel5.stunnel name.conf

Am I missing something?

There is another issue I have with stunnel. How to ensure customer has it installed? First idea was to install it automatically. This means I need to write code that checks which distro, hence the package manager used and then install stunnel. But in this post "Requesting classic confinement for buttermanager ", it was said that a snap is not allowed to install other applications. In that case I can instruct customer to manually install it to use the app but that doesn’t seem very neat.

So is there a way I can automatically install the stunnel snap as a dependency, and even if I could, how do I get around its issues I just mentioned?

  • Certificates and other files.

The client creates a folder .sdp/ in $HOME directory. At first run it will create certificates, security keys and a uuid file with device info hash. The stunnel configuration files are created at every run.

The location is arbitrary. If snap provides a sandboxed file system like iOS, that is also fine. Basically the created files should be persistant, even after updates and should be accessible by stunnel process.

  • Device Information.

We will be fetching device information through appropriate npm packages and terminal commands. But even the npm package needs elevated access to fetch device info. The current terminal command is:

$ sudo dmidecode

If snap has a way to provide these details I will be happy to consider. (We also need to check for the antivirus tools installed, but that is work in progress.)

snaps are/have to be self contained, so shp stunnel as a stage package, wrap a daemon: simple app entry around it and write a hook that disables it on install …

now your application should be able to use snapctl start <whatever-you-named-the-stunnel-service> and snapctl stop …

same as above, ship dmidecode inside your snap and use the hardware-observe (and perhaps also system-observe) interface to allow it to access the required information.

@shrinidhi111 can you please respond to @ogra’s suggestions above? I also agree it would appear that sdpclient could just ship stunnel directly inside itself as a stage-package and plugging various interfaces should provide the necessary accesses. This request cannot proceed without your input.

@shrinidhi111 - ping. This request cannot proceed without the requested information.

@shrinidhi111 - removing this from our review queue for now. When you have a chance to get back to us, we can add it back.