Request for daemon + browser-support for krellian-kiosk

krellian-kiosk is a snap which provides a web runtime for digital signage and interactive kiosks and therefore needs to be both a daemon and have browser-support. Krellian Kiosk is also intended to become an Ubuntu Appliance.

Requesting approval for daemon + browser-support for the krellian-kiosk snap.

Rejected manual review here.

Prototype source code here.


Thanks for making this forum post - the use of browser-support with daemon grants a lot of privileges to a snap (see the previous discussions for a similar request a few years ago for some background on this Suppress the security-snap-v2_daemon_with_browser-support warning for the snap).

Does krellian-kiosk absolutely require the use of browser-support? I understand the wish for daemon is to have long-lived daemon that is automatically started etc - in that case, perhaps the use of the snap_daemon user via system-usernames could help so that the snap doesn’t have to run as root.

However, even in this case, the daemon will still be started as root and it would have to drop privileges to the snap-daemon user, so this doesn’t entirely alleviate the security concern.

As such, if this browser-support is absolutely required, we would need to perform publisher vetting as though this were a request for classic confinement.

Hi Alex,

Krellian Kiosk acts as both a web client and web server. It is essentially a full screen web browser which can be remotely controlled over the Web of Things. I therefore can’t see any way around it being both a browser and a daemon as that is fundamentally what it’s designed to do.

Running as a non-root user would be great, but the application also needs to configure network settings during first time setup (via network-manager) and bind a web server to ports 80 and 443 which I expect requires root access. (It might be possible to bind to different ports and redirect traffic using iptables, but that probably requires root access to configure post-boot as well).

What does publisher vetting involve exactly?



P.S. Might it make sense to request auto-connection of the network-manager interface at the same time?

Are you saying that the browser itself is binding to port 80/443 and manipulating the firewall? If so, the typical design pattern would be to perform all your root actions early, then permanently drop to an unprivileged user. See System usernames for example code on how to do this in a snap-compliant manner.

You might also consider separating your application into different parts which adds security benefits. I don’t know how feasible that is, but eg:

  • run your webserver as a separate daemon, and have it bind to port 80/443 and permanently drop to snap_daemon
  • run your web browser as a separate daemon and either permanently drop immediately to snap_daemon or start is as snap_daemon
  • use configure hooks/etc to setup your firewall settings or have a separate daemon modify the firewall settings

It sounds like your snap would need to plugs network, network-bind and firewall-control (and perhaps network-control).

For use of ‘browser-support’ with a daemon, your snap should be modified to use system-usernames so that the browser process is not running as root. Once that is done, we’ll ask that you continue to use system-usernames for the browser process and assuming you agree, a member of our advocacy will contact you privately and ask a few questions related to your relationship with the software, device, etc.

I’m saying that the application acts as both a web user agent (browser) and web server and the server part binds to port 80/443. As long as the application can bind to port 80/443 (as it currently does) I don’t think it should need to configure the firewall.

It does need to configure the network (e.g. configure a Wi-Fi hotspot, broadcast a service over mDNS and connect to a Wi-Fi access point during first time setup) which can hopefully all still be done as a non-root user via the network-manager interface? (It may also need to re-configure network settings again in future if the network drops for any reason).

OK, I will try to get my head around that, thank you…

I would be open to that, but I’m not sure how feasible it is or how much it would actually help in practice.

An example feature of the application is that a user can control the kiosk remotely using its web interface to tell it to load a given URL:

The way this is implemented using Electron is that an Express.js web server listens for a POST request (or alternatively a WebSocket message) and then tells the system chrome to load the provided URL in its webview by sending a message to the renderer process using Electron’s built-in IPC mechanism (the web server and web content rendering already run in separate processes).

Turning the web user agent and web server into separate executables inside the snap package would mean adding an additional IPC layer for the server process to communicate with the user agent process in order to control it. An example IPC mechanism might be a WebSocket server, which would just be recreating what already exists and adding an unnecessary extra layer of complexity!

If I’ve understood correctly then I would rather avoid this extra complexity if possible as it isn’t needed for any other platforms on which the kiosk application might run.

So for now I will try to implement the system usernames approach and let you know how I get on. I am of course happy to answer any questions about my company and product to assist with the approval process.


@benfrancis please update us on your progress with system-usernames etc - also I assume you still require both daemon and browser-support for krellian-kiosk - if so, the only option then is to do publisher vetting as for classic confinement requests. If this is the case, let me know and we can get the @advocacy team to start the process.