Hacker News new | ask | show | jobs
by Conan_Kudo 2806 days ago
> There is an SELinux policy that attempts to confine snapd itself, which was contributed by the guy working on the Fedora/CentOS package for snapd (though it looks like the policy would also work for openSUSE and Debian SELinux setups, too).

Snappy packager for Fedora here! :)

Yes, it's true there's an SELinux policy that confines snapd, but it does do some limited enforcement of limitations on snaps, too. It's just not as nice as I'd like, but that requires snapd to learn how to work SELinux, which I can't really do...

And yeah, I tested the policy on Debian too, it works! It should work on openSUSE too, though it might need a slight tweak.

> In addition, the majority of snaps are not sandboxed at all anyway, as they operate in "classic" confinement.

I don't think it's the majority _per se_ (since Ubuntu Core can't run those), but most of the popular ones likely do.

1 comments

> I don't think it's the majority _per se_ (since Ubuntu Core can't run those), but most of the popular ones likely do.

No, that's also incorrect if you slice it by popularity. We don't have a public chart easily filtered by these aspects together, but just pick some random samples.

It's also easy to see that based on the low volume of classic snap requests in the forum, vs. the volume of actual snaps published and announced in the open.

My understanding is that we still can't fully confine stuff using Electron (VSCode, Atom, Skype, etc.). Did that change recently?
Not true. The snaps you list are not classic by virtue of being electron. There's plenty of electron apps in the snap store which are not classic, but strictly confined. It's the default for electron apps built with electron-builder.
I don't think that was ever true?

Docs: https://docs.snapcraft.io/build-snaps/electron

Example: snap info electron-quick-start

I thought the seccomp-in-seccomp thing would have messed things up...