Our sandboxed apps won't really protect users

[Daniel J Walsh]

On 09/11/2015 11:16 AM, Michael Catanzaro wrote:
> Hi,
>
> 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
protecting your
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,
Libreoffice, games
this would be a big step forward in securing the desktop, even if some
users continue
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
untrusted
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 discussion: 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
> considering).
>
>> 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
>> -app
>> 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.
>
> Michael