Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of tvhobbs@googlemail.com
 designates 209.85.216.47 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=aFzU/0C5x2t7kawz+Tb4suhK+OFNtEc47QyQtjOpHkPtwlZejtmaMjOqN5rrE+o05+
         gE89TADWkOB/MoqX0A9eKTYhh9U/I3bQjd2iGANlmqxDBCrBYuGxOTgPFHAAIjI67eKa
         SZ+6r4i/ZToYzV4mtJt7md3WSkof2QzLBx7xg=
MIME-Version: 1.0
In-Reply-To: <4CA8E1C7.5090503@zeus.net.au>
References: <4C9DB5BF.8090307@zeus.net.au>
	<50E73BFB09C740C399530A7042EBDC5E@irt.vein.hu>
	<4CA2FDD0.3050809@qcg.nl>
	<1AA9C7A77E07426F8796698DC18D242D@irt.vein.hu>
	<4CA3A83F.6090309@zeus.net.au>
	<77F1E32F67C8D5479858C0C7E93EB46502CFCE1F@WAL-MAIL.global.avidww.com>
	<4CA43F03.3060002@zeus.net.au>
	<77F1E32F67C8D5479858C0C7E93EB46502CFD411@WAL-MAIL.global.avidww.com>
	<4CA5BAF3.9000803@zeus.net.au>
	<4CA71C47.2090809@zeus.net.au>
	<4CA84630.4030708@zeus.net.au>
	<4CA87E7D.5020407@qcg.nl>
	<4CA8E1C7.5090503@zeus.net.au>
Date: Mon, 4 Oct 2010 11:08:09 +0100
Message-ID: <AANLkTik8sZJ4N4xbnvd7VosZdKh0d0xZcwZx+vdJETw-@mail.gmail.com>
Subject: Re: Towards Internet Jini Services (dos attacks) Smart Proxy
 Isolation
From: Tom Hobbs <tvhobbs@googlemail.com>
To: river-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0015175cb75ee12fe80491c7b852

--0015175cb75ee12fe80491c7b852
Content-Type: text/plain; charset=ISO-8859-1

>  Because it's possible and will improve security, I think we should
> investigate it further, this could allow us to unmarshall the proxy and
> determine trust without changing the Jini Service model.  There's still
> Service UI to consider too, but that happens after determining trust.  We
> need to be immune to DOS attacks during the period we're trying to determine
> trust.
>

I don't want to discourage anyone from doing anything, but I find this
concerning.  To my mind, something should either be 100% secure; like
operating systems are (supposed to be), or there should be a clear "download
and run at your own risk".  Things we pay for (buying stuff off the
internet, online banking, hosted services etc) are supposed to be secure and
there are clear SLAs describing what happens if it's not.  Everything else
you download is very much "on your own head, be it".

What I'm getting from these recent discussions is broadly this;

- "We can protect against this kind of threat, but not that one."
- "We can't protect, at all, against this other kind of thread."
- "We can mitigate the consequences of this kind of thread."

And that's only for the kinds of things we can think of.  I agree with Sim
on this one, it feels like we're creating a false sense of security.  The
danger I see in this is that people will either;

1) See our security designs, see that they're incomplete and announce that
"River is insecure".
2) See our secuirty designs, miss what they do and do not provide, and
announce that "River is bullet-proof".

Both of these statements are wrong and both are dangerous.  I'm still of the
opinion that we can provide secure services through trust (that's a
lower-case, none Computer Science "trust") and not through code.  If,
typically, people get their proxies from some kind of "app store" that they
trust, the community can make sure that only trusted services can get onto
the "app store".  If you want to use a less-known and maybe less trust
worthy "app store" then that's up to you.

I'm leaning towards programmatic security being an all-or-nothing affair.
 Since it appears that we can't protect against everything; I'm reminded
that we can lock and bolt the door as much as we like, but if we leave our
Windows unsecure (ha ha) then the bad guys will still get in.

Tom

--0015175cb75ee12fe80491c7b852--