permission override - does it defeat the purpose of sandboxing?

[Winnie Poon]

Just want to thank all the replies on the topic of permission override, very valid points and explanation!  Looks like we had a wrong focus when looking at attack surfaces. 🙂

Regards,
Winnie

________________________________
From: Alexander Larsson <alexl at redhat.com>
Sent: March 5, 2020 12:31 AM
To: Winnie Poon <winniepoon_home at hotmail.com>
Cc: flatpak <flatpak at lists.freedesktop.org>
Subject: Re: permission override - does it defeat the purpose of sandboxing?

On Wed, Mar 4, 2020 at 10:18 PM Winnie Poon <winniepoon_home at hotmail.com> wrote:
>
> > Can you give a real world example where you worry about the users
> > ability to weaken the sandbox?
>
> From the perspective of a legitimate user of the system the approach
> you mention makes sense: The user can decide to trust a flatpak app
> and, at runtime, give it additional privileges to access to their system
> as in your photos example, or they can choose not limit it to just the
> access that the author requested, or if they really don't trust it she/he
> can remove access/devices all together.
>
> However from the perspective of the application (or rather application developer)
> who may not trust the environment in which the app will run this is a problem.
> We want to make sure that if a hacker gains access to a system on
> which our app is installed, that they cannot run our app with elevated
> access/privilege that would give them the opportunity to snoop data or
> intercept messages.

This is not what a sandbox does. There are two domains, the sandboxed
domain and the more trusted outer domain ("the host"). No kind of
sandboxing can protect the things running in it from something in the
outer domain.

If a hacker gains host access on your system, there is no need to use
flatpak override or anything like that to snoop data or intercept
messages, a process on the host has full access to processes and
resources in a sandbox and can do things like ptracing them or
hijacking them in whatever way he wants. This is not something that is
a limitation of flatpak, it is just how security domains work.

> To give some more background, we plan to run our flatpak app on a fully
> locked down system (almost an embedded system) on which a legitimate
> end user has no access to the OS at all. We boot directly into our app
> and the only way the end user can interact with the system is through
> our app. We will of course take as many precautions as possible to prevent
> unauthorized access, but if a hacker does break in we want the sandboxed
> flatpak application to provide and extra layer of defense the will prevent
> the legitimate user's data and activity from being exposed. However if the
> hacker can run our app with elevated access this protection is lost.

The flatpak sandbox is designed to protect the rest of the system
against what the app does. So, if your application is attacked and the
attacker gains execution privileges in the sandbox it cannot see the
files of other apps or other files the user didn't explicitly grant
the app access to. However, if an attacker gains access to the system
in some other way and ends up outside the sandbox, the sandbox is of
no help whatsoever.

As a comparison, say you're using a virtual machine as a sandbox, and
you run a webserver in the VM. If a hacker exploits the webserver he
can access stuff in the VM, but the host OS is safe (unless there is a
VM break-out bug). However, if the hacker somehow gains access to the
host OS, then the entire VM hard-drive is just a file you can read
however you please, and the entire VM memory is just in process you
can attach to and read. There is nothing the VM can do to protect
against this. Again, this is just how security domains work.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20200307/0682c1b5/attachment.htm>