Our sandboxed apps won't really protect users

[kendell clark]

hi
I've been following this thread for a while, and I've got a couple of
questions. Will this xdg-app export to, or be able to grant access to,
accessibility tools, such as orca? I like the idea of sandboxed
applications, regardless of whether they're an imperfect form of
security or not, no form of security is perfect. Is the xdg-app
specification being designed to from the start allow assistive tools,
such as orca, magnifiers, etc to get access to these sandboxed apps? If
not, I'd strongly suggest it be added. This is a chance for
accessibility to be designed in, rather than bolted on later, which is
usually a better solution, imo. I can't speak to how good or otherwise
sandboxing is in terms of security, but it's better than nothing, and it
can only help linux, which is already pretty secure, and very secure
once you add in SELinux.
Thanks
Kendell clark


On 09/11/2015 06:02 AM, Josh Boyer wrote:
> On Fri, Sep 11, 2015 at 1:41 AM, Michael Catanzaro <mcatanzaro at gnome.org> wrote:
>> On Wed, 2015-09-09 at 20:56 -0500, Pete Travis wrote:
>>> As a follower of the discussion, and packager of an application that
>>> might
>>> fall under these requirements, your phrasing here makes me nervous.
>>> I'm
>>> not reading "We will develop infrastructure for distributing xdg
>>> -apps", I'm
>>> reading "We will require infrastructure for development and
>>> distribution
>>> xdg-apps be developed".  Packages not represented in Software are
>>> installed
>>> by users now, and these packages will continue to be installed if
>>> Software
>>> deigns to only expose xdg-apps.
>>>
>>> I'm not sold.  I don't believe that the majority of users consume
>>> Fedora
>>> exactly as intended by this kind of strategy, and I am dubious that
>>> the
>>> project would be better off if they did.  The strength of Fedora is
>>> in both
>>> polish and extensibility.  Extremes in either direction weaken the
>>> appeal.
>>> Look at devassist, for example - in my opinion, the one included
>>> 'application' serving the developer workstation use case.  There's
>>> talk of
>>> dumping it for lack of polish, and talk of deployment methodology
>>> mandates....
>>>
>>> Either I'm totally lost, OR the GNOME spin should rebrand as a
>>> desktop
>>> computing appliance with a wholly curated experience, and the project
>>> should promote some other implementation as a versatile desktop Linux
>>> distribution.
>>
>> Hi,
>>
>> You've posed a hard question that we've been ignoring because it's
>> hard.
>>
>> Your key point is: "Packages not represented in Software are installed
>> by users now, and these packages will continue to be installed if
>> Software deigns to only expose xdg-apps."
>>
>> The compromise solution will probably wind up being that Software only
>> exposes xdg-apps, like you fear, but I'm going to argue that doesn't go
>> nearly far enough. You maybe haven't considered that we have a
>> compelling interest to make sure users can run only sandboxed xdg-apps,
>> period, so that bad guys can't own users' computers by putting custom
>> installers and RPMs up for download on their web sites. But we also
>> want to make sure Fedora remains a general purpose OS that the user has
>> full control over: we're not respecting the user if we limit what he
>> can do like an iThing. The goals are contradictory.
>>
>> If you can do whatever you want, you'll probably install the first non
>> -sandboxed, non-xdg-app-ified third-party app that you want to use. If
>> that becomes commonplace, it will totally defeat the purpose of having
>> application sandboxes: we might as well not bother, because sandboxing
>> all the non-malicious applications does us zero good if the malicious
>> applications simply don't use the sandbox. Analogy: Windows and Java
>> application signing is intended to make it harder to distribute
>> malware. It's also totally worthless, because it's optional, and nobody
>> cares whether an application is signed or not, or even understands what
>> that means. (In fact, it's worse than worthless, it's actively harmful,
>> since it trains users to ignore security questions.) This is *exactly*
>> what is going to happen to xdg-app if we allow running things that
>> aren't xdg-apps. It's also what's going to happen to sandboxed xdg-apps
>> if we allow running unsandboxed xdg-apps. Even if most apps play nicely
>> in the sandbox, you're just going to get owned by the ones that don't,
>> and building the sandbox was a waste of effort.
> 
> That's ignoring the existing security measures we have in place, like
> RPM/dnf requiring signatures on packages and SELinux.  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 best way to solve that problem is to become an iThing, which we
>> definitely aren't going to do, because that would be disrespectful to
>> users and just plain BS. But we have to do that, or we're not
>> protecting users, and that too is disrespectful and BS. So what do we
>> do? Probably find a compromise between the two extremes, which sounds
>> to me like exposing only sandboxed xdg-apps in Software, but that's
>> *really* not enough, because like you say: packages not represented in
>> Software are installed by users now, and these packages will continue
>> to be installed if Software deigns to only expose xdg-apps.
>>
>> Anyway, we need to give you a non-BS answer, and I don't have one,
>> sorry. Maybe somebody else does.
> 
> 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.
> 
> 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.
> 
> josh
>