Visibility of processes originating from other snaps

It seems like it is possible to view processes belonging to other snaps. Should processes ran by other snaps be visible on a need to know basis? Would it be more comfortable to remove this “feature”?

This gist illustrates the issue in more detail. Thanks.

We shouldn’t allow listing arbitrary processes without an interface for it.

@jdstrand What do you think? Where do we stand now in those terms, and what’d the best way to get there?

Any thoughts on this @jdstrand. No doubt not a super deal breaker but unsure if this can be exploited

In theory it can’t be exploited for anything major, since the process list isn’t supposed to contain anything super sensitive on historical grounds (it’s been multi-user for long and the the list was accessible). That said, it’s a bit of a privacy breach which we need to fix at some point.

What we need to be careful about is to not make the system too inconvenient to use on the way to that. There are definitely simple ways to isolate the process space these days, but having proper access to the processes in snaps is important too.

1 Like

I agree with your assessment. Is there a proper process to register this concern? eg in launchpad or Github? Or is this existing forum thread sufficient?

Since your snapcraft.yaml has confinement:strict you shouldn’t need to use --jailmode even with snap try. Can you try again without --jailmode and see if you get the same results?

Background: as a design decision, snaps integrate into the system fully (mount namespace notwithstanding) so that admins, users, etc may use ‘ps’, etc to see processes of snaps that are running on the system and be able to interact with them using traditional tooling, etc. As a result, snaps intentionally are not launched within a PID namespace. In addition to integrating more fully into the system, this means we can allow snaps to interact with each other by various means through snappy interfaces because everything is in the global PID namespace (eg, this is why the htop snap works well when the process-control interface is connected).

In terms of confinement today, it is considered a deficiency in the current sandboxing that snaps are able to view certain files in /proc that belong to pids outside of the snap since this constitutes a (minor) information leak (and we document in the security policy where those leaks are so we can come back and fix them in the future and so that auditors/users/etc understand that the current behavior is a known limitation of the confinement). The medium/long term goal is to fix the sandbox to limit the /proc file accesses to those that belong to the snap. With AppArmor, this will come when kernel variable support is implemented and that is being tracked in upstream AppArmor bug


@elfgoh The conversation here should be enough.

@jdstrand Thanks for the background, and I believe we’re in agreement that medium/long term snaps shouldn’t be able to see processes they don’t own.

Is there any specific value in performing the test without --jailmode? Is it just to investigate the possibility that --jailmode is buggy?

It was just to test the possibility that --jailmode was the cause, but @jdstrand’s explanation above answers that question for us already, that this is a known limitation in the overall confinement