Vmanager Snap Classic confinement

Hello @jdstrand,

Sorry for the delay.

To xdg-open I am passing the path tot he file. Like in the example below.

void OpenFolder(const string& a_folder) {
    string s("xdg-open ");
    if( !a_folder.empty() ) {
        s += a_folder;
        system(s.c_str());
    }
}

I am using snap and snapd 2.28.1

I don’t know how to specify the plugins to the snap yalm.

Greetings,

Michael.

take a look at this snapcraft.yaml in the “plugs:” line you define which interface plugs your app is allwed use, make such a line in your own snapcraft.yaml and make sure the list contains either “desktop” or “unity7” to enable your app to execute xdg-open.

Hello @orga,

Thank you for the quick reply, I just tried what you suggested and got this error:

Error org.freedesktop.DBus.Error.ServiceUnknown: The name io.snapcraft.Launcher was not provided by any .service files
Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files

and here is a look at my .yalm file:

apps:
vmanager:
command: vmanager
plugs: [network, network-bind, x11, opengl, home. desktop, unity7]

Greetings,

Michael.

Ok, so (disregarding the DBus error), you are using xdg-open from the core snap, which is normally what you want because it will allow you to open an external application for the URL in question.

Unfortunately, the xdg-open in the core snap does not handle file:/// URLs. Normally, the non-snappy xdg-open when given a file URL will look at the mime type of the URL you give it and open it with the default application for that mime type. In your case, you give a directory so the file manager is opened.

This is an interesting use case that (at least I) had not considered. @niemeyer and @jamesh, as a thought experiment, let’s consider modifying snapd’s userd to handle file:/// URLs. AFAICT, the expectation of using xdg-open is that the snap would never be given this file again, so it is a one-way action (ie, the snap doesn’t gain access to the file in question, only launches something else on it). An implementation might have userd verify if the specified file is accessible to the snap already (ie, via libapparmor). My main concern is that a malicious snap could exploit bugs in unconfined default mime handlers. For example, there is an exploitable code execution bug in an image library that allows code execution. The malicious snap ships a crafted image then calls xdg-open $SNAP/bad.png, this is in the application’s readable area, so pass that along to the system xdg-open, which opens eog unconfined, which the snap can then control via the code execution bug and break out of confinement. This is precisely what snappy confinement is supposed to address-- any exploitable bugs are supposed to be limited to the snap itself. Part of the problem here is that the user isn’t given a choice to open the file. Limiting this to a directory addresses that but if given the choice, the user could be tricked into opening a crafted file easily enough.

We have some knobs though (that can be used in combination):

  1. userd could just pass file:/// URLs straight to xdg-open
  2. userd could check if the file:/// URL is accessible to the snap, if so, pass to xdg-open
  3. userd could only handle file URLs for directories
  4. userd could only handle file URLs for directories and could check if the file:/// URL is accessible to the snap, if so, pass to xdg-open
  5. userd file:/// URLs use a different DBus API that we only allow in transitional interfaces (eg, desktop-legacy and unity7)
  6. userd file:/// URLs use a different DBUS API that we allow in a separate manually connected interface (or via an interface attribute of desktop-legacy)
  7. userd would only open file handlers under confinement (eg, another strict mode snap)

I was trying to think through if portals could be of use, but I don’t think so-- the file chooser is about giving access to a file to the application so it can do with it what it wants, it isn’t about launching other applications on the requesting app’s behalf.

If we were going to support this, I’m sorta thinking this is perhaps a combination of ‘2’ and ‘5’. Since the user can be phished, ‘3’ and ‘4’ don’t buy us much. Limiting to what the snap can access (‘2’) seems to have merit. ‘2’ and ‘6’ is possible too: it allows us to mediate the file:/// access via snap declaration and user choice. ‘7’ is interesting to think about, but it allows for the calling snap to exploit bugs in the called snap to exfiltrate data; not to mention, I strongly suspect that people would want to call classic snaps.

To more specifically answer you: today you cannot use xdg-open in this manner unless you ship your own xdg-open and have it open an application in your snap. Eg, you ship a small file chooser and an editor and have your xdg-open your file chooser. I realize this probably isn’t an attractive option for you. Of course if this is what you wanted, you wouldn’t need xdg-open at all.

An alternative, today, would be to disable the OpenFolder functionality and provide guidance to your users to open the files themselves outside of your app, at least until snapd/userd provides something better for you. Since strict mode confinement is desirable, I encourage you to consider this option.

If these options are unacceptable, the only option is classic confinement today.

Hello @jdstrand,

This is disappointing, if it wasn’t important I wouldn’t push for it but it is. I have found this snapd implementation of xdg-open, snapd-xdg-open would it work as an alternative if I integrate it in my application?

Greetings,

Michael.

No, snapd-xdg-open is the receiver that used to run in the users desktop session, it used to listen for data from the xdg-open the core snap that @jdstrand mentioned (which is only a special forwarder). With the recent change to have snapd do the user-session part snapd-xdg-open is obsolete, you do not want to have it installed anywhere (neither in the session nor in the snap (where it would be a no-op anyway)).

I think the only proper way here would be to make the new “userd” handle file:/// URLs somehow, but i guess that would need a complete new interface since it will allow access to random files on the filesystem if it does not get properly restricted … (though i guess simply allowing files from $HOME if the home interface is enabled anyway for the specific snap should not be to hard)

Hello @orga,

Thanks for the quick reply. Is there an example you could point me to for inspiration?

Greetings,

Michael.

userd is part of the snapd source, there is nothing i could point you to to “just make this work”, it needs code changes (currently only http, https and mailto get accepted as protocols AFAIK)

I listed quite a few options in my previous post. I think this needs design discussion (which is why I pinged @niemeyer and @jamesh). I think it is possible to support this. The question is whether or not it fits into the snap story (since it weakens the security stance) and if it does, how to expose that to snaps. Tying it to a transitional interface makes some sense to me, because desktop-legacy, x11 and unity7 all are more problematic than calling xdg-open with a filtered file:/// URL.

Hello @ogra, @jdstrand,

Is using system(nautilus home/path/to/folder) an alternative?

Greetings,

Michael

@cmichael - if you are saying this is what snapd could do on behalf of the application, it could, but this is the equivalent of 3 and 4, above. If you are saying that the application could do this, absolutely, but the application would need to ship nautilus and whatever file editors it would want to support (this is a variation on what I said about shipping a small file chooser and editor and using xdg-open to open them).

Hello @jdstrand,

Sorry for silly questions but completely unfamiliar with system dependencies like this, fortunately for macOS and Windows it has been way easier and straight forward to open a folder…

Does this mean that I have to package nautilus, or mention it as dependency? I am not interested in support other file managers.

Greetings,

Michael

It isn’t a silly question at all! :slight_smile: There are two things at play here:

  1. strict mode snaps run in restricted environment where they may only run things that they ship, run things that can run under the same confinement as the snap and/or talk to an out-of-process helper to do things on the snap’s behalf
  2. the Vmanager snap itself is taking a shortcut to avoid code complexity and calling xdg-open rather than providing a user interface for navigation itself (importantly, I’m not saying that the shortcut is wrong, just that this is what it is doing)

In the traditional (aka classic) world where everything in the user’s session is considered trusted, applications could do literally anything, but in the modern app-centric world (eg snaps), applications need to only access other resources in controlled ways.

It is completely understandable that you don’t want to ship a file manager and editor (I mentioned this above too). Your comment about opening a folder is interesting: it is easy to open a folder with snaps if you are using a toolkit that supports it. Eg, using the GTK/Qt file chooser works fine within a snap for opening files. Perhaps there is something in the toolkit you are using that can achieve what you want? Barring that, and assuming you don’t want to ship a file manager and editor (quite reasonable IMO), then what that leaves is talking “to an out-of-process helper to do things on the snap’s behalf”, which is precisely what my comments on xdg-open are meant to address and get the ball rolling for a design discussion.

(Note: that design discussion will happen; it just so happens people were on/going on holiday when I mentioned this)

Hello @jdstrand,

And thanks for the clarification. I understand what you mean with App Centric confident which is a nice thing and I am very pro that. but I my case all though it might look like a shortcut it is not and it doesn’t open the user to any vulnerabilities the path to the folder is hardcoded the user can’t exploit this by any way. The suggested QT solution is not a solution for me. Our toolkit is build in house, and a base for multiple application. Something can’t just be replaced or changed which doesn’t even need to be.

To further in this subject as I mentioned I have already achieved that on Windows( which provides a c++ toolkit that I could use for that operation) and macOS(which all though has stricter confidents it still gives you a way to achieve that). My point is that I would expect snap to follow in those steps. Either provide a toolkit that solves the severed tight cause by sandboxing or provide a way.

Because for example in my case, Its to expensive to try and figure out how to ship an explorer or any workaround for an operating system with the smallest margin, and for something so simple. Which for me it drives me away from snap and not to close, and its a shame, because I really like the idea.

Unfortunately, I have to park it for now. But please include me in the conversation, I want stay up to date on the subject.

Greetings,

Michael.

@cmichael - I think you misunderstood my comments. I was describing the current situation and what future work would need to be done to support your snap in strict mode, and pulling others in so they could participate in the design of that future solution that would accommodate opening a folder more easily within snaps where their chosen toolkit does not do what they require. Part of the process for classic confinement requests is gathering information for why classic confinement is required, and we’ve done that. Way back in Vmanager Snap Classic confinement I gave options for you. Since then I was only answering questions and trying to push the xdg-open helper design forward. I apologize if that was unclear.

Since you want to use xdg-open and do not want to modify your application or snap, then only classic confinement is available to you today.

@evan - can you or someone from your team perform the other parts of Process for reviewing classic confinement snaps?

Hello @jdstrand,

Any updates on this issue?

Greetings,

Michael.

Actually, yes. xdg-open now supports file:// for files and directories as of 2.32 (see https://github.com/snapcore/snapd/pull/4766 and https://github.com/snapcore/snapd/pull/4794). Can you try snap refresh core --edge and see if it works for you?

Hello @jdstrand,

Thank you! I will check it today. One question please bare with me, is there a release notes page? I couldn’t find this info on GitHub.

Greetings,

Michael.

@mvo often lists the release notes here in the forum. Perhaps the snapd release team would want to consider utilizing github more for this as well.