Browser-support/daemon permission request

store-requests
#2

Thanks for creating this request. Does your snap actually change users to the snap_daemon user after startup? Just adding system-usernames the the snapcraft.yaml is not sufficient, the snap needs to explicitly change to this less privileged user itself.

I assume you followed the example in https://github.com/MirServer/iot-example-graphical-snap which looks to be packaged by @alan_g - Alan can you advise whether this example snap already includes the code to drop privileges to the snap_daemon user, and if it doesn’t, it would be worth adding that for future users of the snap.

#3

It doesn’t. That sounds like a reasonable addition, but I would have to investigate the details of how to do it.

#4

IIRC our last try of using snap_daemon in context of a kiosk setup in another thread failed badly and the user got permitted the interfaces regardless at the end… (sadly I can’t find that thread right now)

#5

Found the thread I was referring to above …

#6

Thanks @ogra. That makes the issues clear, if not the solution.

#7

A more recent thread implies that dropping privileges can work, but I can’t find the referenced code anymore.

#8

Hey guys,

I didn’t add anything regarding system-usernames to our project besides what I posted. @alan_g (thanks for all your work) Is dropping privileges something that you’ll add to the tutorial/repo soon?

#9

If someone can propose the changes needed I’ll do that. Otherwise it will have to wait until I have time to research how to achieve this.

Note however, even with those changes there will still need to be a security review.

#11

The code that ultimately worked is here. For what it’s worth, I abandoned this idea due to this nightmare of dropping privileges which caused other issues down the track interfacing with hardware etc.

It may work for you, but I ended up rewriting the project in Qt.

1 Like
#12

Thanks @jaydensmith, that will make it easier to figure out possible changes to the example.

OTOH if dropping privileges causes other problems that may still not be the best way forward.

#13

you’d have to run a separate daemon that does not drop the privs inside your snap and then talk to it from the binary with dropped privileges through a socket or dbus or some such …

#14

I’d like some input here from the security team (@alexmurray?): Would adding code to drop privileges help get electron snaps approved?

Dropping privileges does reduce the exposure to the electron process, but there would still a need for a security review and an exception based on trusting the publisher.

As noted by @ogra above, there may need to be “a separate daemon that does not drop the privs” (that may not need browser-support though).

#15

That is what I did. I ran into other issues, though they were quite specific to what I was trying to do.

#17

Did you test utilizing serial devices or a camera with your previous electron implementation by chance?

#18

Yes, like @ogra said I had to run a separate daemon and open a socket with generous permissions.

Then you can listen on the socket in your electron app.

This was only a crude implementation. There may be a better, more secure way.

1 Like
#19

It is the combination of browser-support with daemon as the root user (which is what is done by default for snaps) that is the issue - essentially this combination allows a snap to take ownership of a device - which is why we then require vetting of the publisher etc. However, even if a snap drops permission to the snap_daemon user there is nothing stopping the publisher from removing such functionality in the future, hence why even if the snap_daemon user is used we still do the publisher vetting.

In general though, if the privileges can either be reduced by having the daemon within the snap run as the snap_daemon user - or by splitting these between two different processes within the snap - one that runs as root but does not have browser-support and one that runs as snap_daemon with browser-support - then that seems reasonable and the security review seems tractable in either case (this is still better than having the whole thing run as root with browser-support).

#21

@alexmurray Would there be a way to release our app on a dev channel or temporarily on some sort of public channel (That’s not a brand store) while this gets worked out? We are trying to test creating an ubuntu core image for a large client and need to include our app in the image assertion.

#22

ignoring the fact that the snapd team is under heavy load and understaffed currently, i wonder if long term we could not take away the pain from the packager by having the snapd side handle the privilege dropping instead so that not the packager has to apply hacks and scripts to drop privs but simply can just define something like daemon: unprivileged in the snapcraft.yaml …

#23

@flightknight22 I understand there is some urgency for you. And you can help progress things.

  1. For the security team to approve your snap it needs, among other things, to drop permission
  2. You can see an example of doing this: You can try that logic and see if it works for you

If it works, it would be nice if you can share the solution by proposing changes to the example. I would be able to review that earlier and faster than working out the changes myself.

#24

@alexmurray

I can implement the example that @jaydensmith provided, but it won’t be a valid solution for our situation either as we will run into the same hardware interfacing issues.