<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.
<span id="🙂">🙂</span><span id="🙂"><br>
</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span id="🙂"><br>
</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span id="🙂">Regards,</span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span id="🙂">Winnie</span><br>
</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Alexander Larsson <alexl@redhat.com><br>
<b>Sent:</b> March 5, 2020 12:31 AM<br>
<b>To:</b> Winnie Poon <winniepoon_home@hotmail.com><br>
<b>Cc:</b> flatpak <flatpak@lists.freedesktop.org><br>
<b>Subject:</b> Re: permission override - does it defeat the purpose of sandboxing?</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">On Wed, Mar 4, 2020 at 10:18 PM Winnie Poon <winniepoon_home@hotmail.com> wrote:<br>
><br>
> > Can you give a real world example where you worry about the users<br>
> > ability to weaken the sandbox?<br>
><br>
> From the perspective of a legitimate user of the system the approach<br>
> you mention makes sense: The user can decide to trust a flatpak app<br>
> and, at runtime, give it additional privileges to access to their system<br>
> as in your photos example, or they can choose not limit it to just the<br>
> access that the author requested, or if they really don't trust it she/he<br>
> can remove access/devices all together.<br>
><br>
> However from the perspective of the application (or rather application developer)<br>
> who may not trust the environment in which the app will run this is a problem.<br>
> We want to make sure that if a hacker gains access to a system on<br>
> which our app is installed, that they cannot run our app with elevated<br>
> access/privilege that would give them the opportunity to snoop data or<br>
> intercept messages.<br>
<br>
This is not what a sandbox does. There are two domains, the sandboxed<br>
domain and the more trusted outer domain ("the host"). No kind of<br>
sandboxing can protect the things running in it from something in the<br>
outer domain.<br>
<br>
If a hacker gains host access on your system, there is no need to use<br>
flatpak override or anything like that to snoop data or intercept<br>
messages, a process on the host has full access to processes and<br>
resources in a sandbox and can do things like ptracing them or<br>
hijacking them in whatever way he wants. This is not something that is<br>
a limitation of flatpak, it is just how security domains work.<br>
<br>
> To give some more background, we plan to run our flatpak app on a fully<br>
> locked down system (almost an embedded system) on which a legitimate<br>
> end user has no access to the OS at all. We boot directly into our app<br>
> and the only way the end user can interact with the system is through<br>
> our app. We will of course take as many precautions as possible to prevent<br>
> unauthorized access, but if a hacker does break in we want the sandboxed<br>
> flatpak application to provide and extra layer of defense the will prevent<br>
> the legitimate user's data and activity from being exposed. However if the<br>
> hacker can run our app with elevated access this protection is lost.<br>
<br>
The flatpak sandbox is designed to protect the rest of the system<br>
against what the app does. So, if your application is attacked and the<br>
attacker gains execution privileges in the sandbox it cannot see the<br>
files of other apps or other files the user didn't explicitly grant<br>
the app access to. However, if an attacker gains access to the system<br>
in some other way and ends up outside the sandbox, the sandbox is of<br>
no help whatsoever.<br>
<br>
As a comparison, say you're using a virtual machine as a sandbox, and<br>
you run a webserver in the VM. If a hacker exploits the webserver he<br>
can access stuff in the VM, but the host OS is safe (unless there is a<br>
VM break-out bug). However, if the hacker somehow gains access to the<br>
host OS, then the entire VM hard-drive is just a file you can read<br>
however you please, and the entire VM memory is just in process you<br>
can attach to and read. There is nothing the VM can do to protect<br>
against this. Again, this is just how security domains work.<br>
<br>
-- <br>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<br>
Alexander Larsson Red Hat, Inc<br>
alexl@redhat.com alexander.larsson@gmail.com<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>