121–130 of 264 posts
Earlier quoted context omitted.
“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.
It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.
Earlier quoted context omitted.
Yes. The sandbox tool used by Flatpak is "bubblewrap", which has an overview here: https://github.com/projectatomic/bubblewrap/blob/master/READ... There is nothing against Flatpak using user namepsaces when the developers feel a bit more comfortable with that, though.
Are you one of the developers/speaking for them? That warning is pretty old.
Earlier quoted context omitted.
> We'll see in a decade or two what software is even remotely in a usable state still. Most distributions need non-free explicitly enabled, so almost all packages are open source, so it is irrelevant to distro packaging format.
Open source doesn't ensure it'll even build against new compilers, libs, language runtime, and all the other stuff we're reinventing all the time to keep the hamster wheel spinning. What open source desktop apps are you using that need sandboxing anyway all of the sudden? GIMP, Inkscape, Audacity? Come on.
Yep - all of those. GIMP has scripting capabilities and exposure to vulnerabilities via image codecs, same as Inkscape, and Audacity could be linked to ffmpeg, which is a huge attack surface.
Earlier quoted context omitted.
> 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 a…
My understanding is that we still can't fully confine stuff using Electron (VSCode, Atom, Skype, etc.). Did that change recently?
Docs: https://docs.snapcraft.io/build-snaps/electron
Example: snap info electron-quick-start
Earlier quoted context omitted.
They use a lot of similar techniques. One big difference is that docker uses user namespaces and flatpak does not. I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. It sounds like the bigger issue isn't that the underlying technologies are fundamentally better or worse, but that the de facto configurations are wors…
> I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. binctr looks like an interesting solution to tackle this issue. [1] https://blog.jessfraz.com/post/getting-towards-real-sandbox-... [2] https://github.com/genuinetools/binctr [3] https://news.ycombinator.com/item?id=18180276
I worked quite a bit on getting this userspace stuff together (though of course the kernel work was done by much more clever people than myself :P).
[1]: https://github.com/rootlesscontainers [2]: https://github.com/openSUSE/umoci
Earlier quoted context omitted.
“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.
It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.
Earlier quoted context omitted.
With the exception of snaps running on Ubuntu and Solus, snap confinement is limited. Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement, currently. Solus imports these changes into their kernel, though I don't trust the changes much because they haven't undergone formal review and have been approved by the kernel developers. So, for example, on Fedora, Debian, CentOS, or…
> Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement, The AppArmor patches have been largely upstreamed by Canonical, and improvements continue to float upstream constantly. So claiming it's not being reviewed isn't accurate. > * Canonical doesn't know how to work with SELinux at all, and doesn't want to learn how to That's disingenuous. Canonical works with many parties,…
So, there cannot be a third-party/self-hosted snap store ? That seems like a major limitation.
Earlier quoted context omitted.
They use a lot of similar techniques. One big difference is that docker uses user namespaces and flatpak does not. I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. It sounds like the bigger issue isn't that the underlying technologies are fundamentally better or worse, but that the de facto configurations are wors…
Yes. The sandbox tool used by Flatpak is "bubblewrap", which has an overview here: https://github.com/projectatomic/bubblewrap/blob/master/READ... There is nothing against Flatpak using user namepsaces when the developers feel a bit more comfortable with that, though.
Earlier quoted context omitted.
With the exception of snaps running on Ubuntu and Solus, snap confinement is limited. Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement, currently. Solus imports these changes into their kernel, though I don't trust the changes much because they haven't undergone formal review and have been approved by the kernel developers. So, for example, on Fedora, Debian, CentOS, or…
> Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement, The AppArmor patches have been largely upstreamed by Canonical, and improvements continue to float upstream constantly. So claiming it's not being reviewed isn't accurate. > * Canonical doesn't know how to work with SELinux at all, and doesn't want to learn how to That's disingenuous. Canonical works with many parties,…
I'm assuming with "LSM stacking" that you mean having both AppArmor and SELinux operate concurrently on a system, since you can currently have kernels that have both enabled, but only one at a time active.
Are you going to convince Red Hat to enable AppArmor and support stacking SELinux and AppArmor in RHEL? What about helping to maintain AppArmor support in Fedora? Without that piece, that's not a valid or useful solution because you're hoping for something that won't help any of those people (like me!) at all.
I'm pretty sure that everyone will say no to the idea of combining AppArmor with SELinux, since it's basically insane and requires developing and maintaining policies for both that don't conflict with each other. Having written these things for my apps, I wouldn't wish the combination of both on a single system on my worst enemy. That's a lot of security check policies to work through!
> We also had exchanges in the forum to discuss the implementation of actual backends in snapd to support it, but Canonical indeed won't pay for the cost of implementation until there's a reason to do it. That's business as usual and pretty straightforward.
Sure, but if people do keep asking for full support, that implies having SELinux support to enable full confinement. As I said above, unless you intend to actually do the work and convince Red Hat to make the necessary functionality available, you're going to need to support SELinux as a proper backend.
> Well, yes, it has created the project and maintains it actively for years now. You're welcome as a contributor.
I think you missed the point. But sure, maybe. If there wasn't the CLA to get in the way... Why do you have that when you already offer it under a nice copyleft license?
> CVE-2018-11235 reported and fixed more than 4 months ago. Flatpak VSCode, Android Studio and Sublime Text still use unpatched git version 2.9.3. Wait, what? We explicitly do not ship a Flatpak version of Sublime Text, and no version of Sublime Text comes with git. After such inaccurate information, I can’t help but question the rest of the article.