On Fri, Jul 14, 2017 at 09:29:29PM +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? No, IMHO. The approach of SELinux vs. "namespace+seccomp jail" (let's call that what flapak as well as systemd does) is realized at a different level. First SELinux policy is a global policy that ties the labelling of all files, all process, and all users, so it must be maintained centrally. Second, the area of exposure is enormous, because SELinux must decide the interaction between any process and any file type, at the level of individual syscalls. That's why we are always playing catch-up with the policy. With the "namespace+seccomp jail" approach, one starts with a very limited view of the file system, with large swaths of it additionally read-only/nodev/noexec. On top of that specific "things" are made visible, on a much higher level. So the policy is decentralized (the sandbox makes specific mechanisms possible, but the application packagers decide the details of the policy), and written at a higher level. I expect that once the implementations of various "portals" have matured, wring flatpak policy will be quite easy. (You can see the same with systemd units: some have quite restrictive policy, including seccomp filters and strong filesystem visibility limitations, yet this doesn't seem to be causing frequent issues.) Zbyszek > 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 > > 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. > > Some apps (e.g. virt-manager) need access to your ssh-agent socket but > you certainly don't want to make it available to every single app. This > is just a single instance of the general case of a program talking to > one of the numerous services that may run on the host. > programs depending on user configuration. > > You want some environment variables passed through to the sandboxed app > (EDITOR or whatever) but not others (e.g. AWS_SECRET). How is the > Flatpak app even going to execute your favorite editor? > > Someone is going to have to write all the policy for that. Otherwise, > the only apps that Flatpak will be able to handle properly are going to > be trivial mobile-style apps that don't interact with anything but their > developer's cloud services. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
