Re: (in)SECURITY: mozilla-bonobo



On Fri, 2003-12-05 at 14:53, Fabio Gomes wrote:
> Em Sex, 2003-12-05 às 16:06, Jean Bréfort escreveu:
> > Le ven 05/12/2003 à 13:01, Fabio Gomes a écrit :
> > > > 2a. Instead of adding a flag, use the "bonobo:supported_uri_schemes" oaf attribute.
> > > >     This way, one can limit the used components to those that advertise that they
> > > >     handle the protocols (http(s)/ftp) that are used to transfer files on the net.
> > > >     Supposedly components that are aware of those protocols would also handle
> > > >     untrusted data.
> > > > 
> > > Great. This wold solve the problem.
> > 
> > May be it solves the problem, but most components do not advertise this
> > attribute. I searched which actually do. The list is quite short:
> > several Nautilus components, fontilus and File_Roller, none of which
> > being used by mozilla-bonobo or has http or ftp as content. 
> > 
> 
> Hmm. So maybe the 'safe for web' flag could be a better idea.

There's also the issue that "support for HTTP" has nothing to do with
safety.  A company can have an intranet with HTTP served documents
(perhaps use DAV) which are completely trustworthy, while documents
served from http://hacks.l337.foo are not safe.

Which brings up a slightly different situation - not only do we need the
component to advertise whether it's allowed to be used for untrusted
documents, but also, how do we know which are untrusted, and how do we
tell the component that?  Documents from servers on my local network I
trust (and I can get to any of them using SMB or NFS as is anyhow), but
not the outside world.

This complicates the situation quite a bit.  First, we need a way to
setup trusted locations.  GConf keys for "trust local host", "trust
local network", and/or a list of trusted hosts/domains would likely be
needed.  Applications would need some way to check if the document
they're getting is from a trusted or untrusted source, so they can
change their behaviour as appropriate (I *want* my Word Processor to
open and read docs from the web, but I *don't* want it to run any kind
of dangerous macros or features that utilize extra file/socket I/O).  

Applications (and the downloader/browser) may then also want a way to
tell the user about this.  Something like, "You are downloading this
document from an untrusted third party ([domain name]).  This document
may contain viruses, spyware, or other malicious software components
which can damage your computer or your data.  [ ] Always trust this
source.  [Cancel] [Open Trusted] [Open Untrusted]"

We could even start getting *really* fancy and attach GPG signing to any
document type we possibly can, so (for example) I could "trust" Ximian,
and be able to open any Ximian-authored document, even if it's been
mirrored to another site.  I don't know that this is feasible for any
but a few uncommonly used document types, however.  It would be nice to
keep this standardized across the desktop rather than have each
application re-implement it in a slightly different way, tho.

To be honest, it's probably best the app/component be completely in
charge of determining trust-worthiness/safetiness.  We need to handle
the situation for when the user selects "File->Open" and enters a URL
just as much as we do when the user clicks on a link in a web browser,
opens an attachment in an email (just as dangerous if not more so in
today's state of affairs), or opens a document from a remote file system
browsed in Nautilus.
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]