On 09/11/2015 11:16 AM, Michael Catanzaro wrote:
I will start with a TL;DR summary of my mail: we don't have to sandbox
our xdg-apps, like you say. But if we do, we should only allow running
sandboxed apps, even if it means we lose most of our apps. Otherwise,
the sandbox is pointless. It's a hard choice we'll need to make. Right
now, we're headed towards developing a useless sandbox, which is silly,
and it's time to apply the breaks and rethink that.
Sandboxing apps is about
protecting your desktop from the app, Not
app from unsandboxed apps on your desktop. If we had a sandboxed
firefox when a firefox vulnerability happens, then my ~/.ssh content is much
less at risk. Similarly my financial data and other financial data is
not at risk.
If we could sandbox the largest GUI Apps like firefox, evince/acroread,
this would be a big step forward in securing the desktop, even if some
to download apps from hackme.com
On Fri, 2015-09-11 at 07:02 -0400, Josh Boyer wrote:
> That's ignoring the existing security measures we have in place, like
> RPM/dnf requiring signatures on packages
This isn't true; you can install unsigned packages whenever you want,
just by clicking through (well, keypressing-through) the warning from
dnf. If you've installed RPMFusion, you've done this.
Yes although most
people have not, or only a few packages. Sandboxing apps
is about protecting you from bugs in trusted apps, not about preventing
apps that you install bypassing security.
> and SELinux.
SELinux is very important, but the security model is completely
different: it's designed to protect benign but buggy applications from
being owned by malicious input. We're trying to protect against
applications that are themselves malicious. The malicious app is simply
not going to ship with an SELinux policy that constrains it from doing
the bad things it wants to do. Actually, it will not ship with an
SELinux policy at all, because it's not mandatory to write an SELinux
policy, so nobody does.
We can't currently use SELinux to lock down apps
because of the way
the desktop is designed, if we move to a sandboxed app environment, we
can take advantage of it to enhance the security of the apps.
Let's agree on the attack model before we continue the
attacker's goal is to read some file it's not supposed to from the
user's home directory. It's not trying to find some kernel exploit for
privilege escalation, because it doesn't need any privilege escalation:
it can do all the bad things it wants to do without that. Stopping it
requires xdg-app, or a similar technology, or a very restrictive
default SELinux policy that breaks everything (which is worth
> Sure, if users
> force install everything then yes they can have their systems owned.
> This has always been true and xdg-apps doesn't present a new wrinkle
> at all here.
The goal should be to make it sufficiently difficult and scary to force
install things that a large majority of users will decide not to, but
you still can if you really want to.
> I think you're taking too hard a line on this. Yes, possibility
> exists for people to screw up their own machines. It will always
> exist. That doesn't mean the infrastructure we have today and the
> xdg-apps work being done is worthless.
> I'd also contend that users don't care about xdg-apps. Really, they
> probably don't. If you tell them it will run anywhere and it's
> sandboxed they'll say "oh, that's cool" and then get back to using
> their app. The group that gets the majority of the benefit of xdg
> is developers because it makes publishing their work in a secure and
> well supported way even easier.
> So I don't really agree with your BS assertion on either side. The
> compromise is pretty simple. We provide applications in Software
> because Software exists to show users what applications can be
> installed. It shouldn't matter what deployment technology the apps
> use, as long as they come from a trusted source.
That's one possible choice for us. We can do it. xdg-apps still provide
good benefit for developers as a cross-platform way to deploy
applications. But then there is no point in sandboxing the xdg-apps,
because the optional sandbox doesn't protect users, and it's
inconvenient for developers, so it's more harm than good. We'll miss
out on the tremendous security benefits of sandboxed applications.
That's a valid choice for us to make, though. It might be the best
choice, because there is a huge cost to pay in losing existing apps if
we want to mandate the sandbox! It's going to be hard -- perhaps
unrealistically hard -- to tell developers all their apps have to
change, and to tell users old apps can't be installed anymore. But if
we don't do that, we should give up on the plans for sandboxed
applications, because it's also unrealistic to expect malicious
applications to use the optional sandbox.
We could define some subset of applications that are allowed to not use
the sandbox, say all the existing packages in the Fedora repositories,
but it's not hard to get a malicious application into Fedora, or take a
non-malicious application and make it malicious, so again, the sandbox
provides only quite limited benefit. (We're completely reliant on our
upstreams and our packagers to never add bad stuff.)
> If you want to make non-sandboxed apps more secure, then perhaps work
> could be done to create sandboxes on-the-fly for regular RPMs. That
> would be difficult, but it would provide an added layer of security.
> It wouldn't necessarily be an xdg-app as that is more than just
> sandboxing, but creating a new namespace/Docker container for apps
> during RPM install might be possible.
This might well happen, but it can't work well. The thing is, either
applications require changes to be useful when run in the sandbox, or
the sandbox isn't good enough. LibreOffice isn't going to be a very
great app if it can't see any of your files when you run the file
chooser, and if the files it saves can't be accessed by other apps. And
the sandbox is worthless if it lets LibreOffice access files without
going through the file portal. But I argue that's the fate that should
await applications that aren't ported to use the portals provided by
the sandbox: apps should be sandboxed automatically, even if the result
is that they're broken.
I'm picking on LO just as an example; Alex already has a working demo
of LO using the file portal. The big apps will be taken care of by
developers who care; it's the smaller apps that will be out of luck.
But then we lose users when their old apps don't work properly. Or we
lose users because we didn't let them run the old apps at all.