Re: F27 System Wide Change: Graphical Applications as Flatpaks

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

 



On Fri, 2017-07-14 at 21:29 +0200, Lars Seipel wrote:
> On Tue, Jul 11, 2017 at 11:26:04PM -0500, mcatanzaro@xxxxxxxxx wrote:
> > But we have not been. Very few applications actually have SELinux
> > profiles,
> > and they are all maintained downstream rather than upstream. The
> > volume of
> > erroneous SELinux denials in Bugzilla is too high, and the response
> > time for
> > fixing them too slow. SELinux profiles work best when they are
> > maintained
> > upstream by application developers who are familiar with SELinux,
> > not by
> > SELinux developers who are unfamiliar with the application.
> 
> We do have the same issue with sandbox policies for Flatpak,
> no?  This is the hard part of any sandboxing system and (judging from
> the current docs) Flatpak hasn't tackled it yet.
>
> A Flatpak app currently requires the following incantation to access
> the host's dconf, so that it can behave like its users would expect:
> 
> > --filesystem=xdg-run/dconf
> > --filesystem=~/.config/dconf:ro
> > --talk-name=ca.desrt.dconf
> > --env=DCONF_USER_CONFIG_DIR=.config/dconf

I think you've found a note in the docs pointing out one spot where
things aren't completely solved yet, and taken that as an example of a
huge class of problem, while that huge class of problems actually does
not exist.

> Now, while this specific dconf issue might get solved at some point,
> dconf won't be enough for the vast majority of useful apps. All the
> crap that lives in the various dot files in your home directory and
> elsewhere on the system and that affects the behaviour of a program
> needs to be made available to the app. Other things must not be, such
> as everything containing secrets.

You are over-estimating the amount of separate files that need to be
visible to an application. Other than their own files, most
applications just read standard files out of /etc, and those can be
propagated or stubbed out as necessary.

One big advantage of the namespace approach over the SELinux or seccomp
approach to create a sandbox is that if an application looks for some
file that is not exposed to the sandbox, it's just not there - it's not
a permission error or a crash.

But, yes, complex applications will not just sandbox as is - and to fix
that poking holes is not sufficient - you need to find safe ways of
doing the same things. The Flatpak model is to expect code changes in
applications, and expect that those code changes will happen upstream.

Owen
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [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