Re: LibreOffice packages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/5/23 16:35, Michael Catanzaro wrote:
> On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb 
> <sgrubb@xxxxxxxxxx> wrote:
>> Yes. And how does it's security model work?
> 
> The security model is that the application is assumed to be compromised 
> by malicious input and is trying to do evil things to the host system, 
> like read your home directory and send copies of your files to a 
> ransomware operator or nation state. Linux namespaces plus seccomp 
> filters are used to confine applications to prevent them from messing 
> with the host system, or reading your personal files, etc.
> 
> It's great in theory. Problem is, as a transition measure to encourage 
> developers to adopt Flatpak, you can give your application extra 
> permissions that totally break the security model, and this is 
> extremely common in practice. You should only trust applications that 
> don't do this, but most apps do. See [1] for a discussion of this.
> 
> [1] 
> https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html
> 
> There are different degrees of badness. E.g. Epiphany, which I 
> maintain, has a sandbox hole that allows it to read and write your 
> Downloads directory, and another hole that allows it to talk to 
> Geoclue. These are both unacceptable, but certainly not as bad as 
> allowing read/write access to the user's home directory or root 
> filesystem, which many apps actually do.
> 
> Flatpak could be pretty darn secure, but only if we stop allowing this, 
> and I fear that would likely result in applications abandoning the 
> platform. This is a major threat IMO. I'd love to see more effort 
> towards improving our portals so that applications don't need to use 
> static permissions anymore. We need to really clamp down on this so 
> that users can trust the Flatpak ecosystem.
> 
>> What is the root of trust?
> 
> I think there is no root. A GPG key is provided when installing a 
> runtime or application.
> 
>> Are they signed by a Fedora key that I already
>> have?
> 
> Nope (except presumably for Fedora Flatpaks).
> 
>> How can we verify it's integrity?
> 
> I think the GPG keys are trust-on-first-use.
> 
>> Once installed, how do I verify it's
>> integrity? How do I check if anything has been modified?
> 
> I don't know. Non-Fedora Flatpaks are stored using ostree, so people 
> familiar with ostree would be able to answer this question. Fedora 
> Flatpaks are OCI containers, so people familiar with OCI containers 
> would know about that.
> 
> ostree is a "git for binaries" and you can detect normal non-malicious 
> modification by looking at the history, e.g. `flatpak remote-info --log 
> flathub org.gnome.Platform//44`; however, this only tells you when 
> something changed, not what actually changed.
> 
>> Does it integrate
>> well with SE Linux,
> 
> No. selinux is entirely outside the Flatpak security model because 
> Flatpak is a cross-distro tool and selinux is not used outside Fedora 
> and Red Hat distros.

Fedora could, of course ship its own SELinux policy for Flatpak (and I
recommend this), but Flatpak will not (and cannot reasonably be expected
to) integrate with SELinux natively.

>> IMA, fapolicyd, or openscap?
> 
> I'm not familiar with these technologies, but I think the answer is: no.
> 
>> On a locked down system, are
>> there sysctls  that I have undo such as user namespaces?
> 
> Technically, Flatpak can work without user namespaces, but this is a 
> legacy configuration and it only works if bubblewrap (/usr/bin/bwrap) 
> is built to use suid root instead of user namespaces, which is not 
> recommend and which we do not do in Fedora. (I think Debian maybe still 
> does this?) So it will surely break if you disable user namespaces, but 
> you might be able to make it work by rebuilding your own bubblewrap 
> instead of using Fedora's.
> 
> The Flatpak sandbox does not attempt to guard against kernel bugs -- it 
> can't, because it has to allow access to all syscalls that applications 
> might reasonably want to use -- so if you don't trust the kernel to be 
> secure (including user namespaces), Flatpak is not the tool for you.

Could Flatpak be changed to use e.g. KVM + crosvm for isolation?  Flatpak
does (via seccomp) prevent applications from creating _new_ user namespaces.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux