Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Date: Sun, 31 Jul 2016 19:20:01 +1000 (AEST)
From: Peter <jini@zeus.net.au>
Subject: Re: another interesting link
To: "dev@river.apache.org" <dev@river.apache.org>
Message-ID: <993b43599315a90275e650af75e7c280@org.tizen.email>
MIME-Version: 1.0
Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="8323328-712294642-1469956801=:1280"
archived-at: Sun, 31 Jul 2016 09:20:33 -0000

--8323328-712294642-1469956801=:1280
Content-Type: TEXT/plain; CHARSET=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

=C2=A0=0A=C2=A0=0A=C2=A0=0A=C2=A0=0A=C2=A0=0AThanks=C2=A0Micha=C5=82,=0A=0A=
Comments inline below.=0A=0ASent from my Samsung device.=0A=C2=A0=0A=C2=A0=
=C2=A0Include original message=0A---- Original message ----=0AFrom: Micha=
=C5=82 K=C5=82eczek <michal.kleczek@xpro.biz>=0ASent: 31/07/2016 02:41:54 a=
m=0ATo: dev@river.apache.org=0ASubject: Re: another interesting link=0A=0A=
=C2=A0>>=C2=A02.=C2=A0proxy=C2=A0codebase=C2=A0jars=C2=A0contain=C2=A0a=C2=
=A0list=C2=A0of=C2=A0requested=C2=A0permissions=C2=A0to=C2=A0be =0Agranted=
=C2=A0to=C2=A0the=C2=A0jar=C2=A0signer=C2=A0and=C2=A0url=C2=A0(client=C2=A0=
need=C2=A0not=C2=A0know=C2=A0in=C2=A0advance). =0A=0AThis=C2=A0one=C2=A0is=
=C2=A0tricky: =0A1)=C2=A0It=C2=A0is=C2=A0not=C2=A0always=C2=A0possible=C2=
=A0to=C2=A0specify=C2=A0fine=C2=A0grained=C2=A0permissions=C2=A0statically =
=0A(for=C2=A0example=C2=A0we=C2=A0want=C2=A0to=C2=A0restrict=C2=A0the=C2=A0=
connect=C2=A0permission=C2=A0to=C2=A0certain=C2=A0hosts =0Aonly=C2=A0and=C2=
=A0the=C2=A0hosts=C2=A0are=C2=A0only=C2=A0known=C2=A0at=C2=A0runtime) =0A2)=
=C2=A0It=C2=A0is=C2=A0really=C2=A0an=C2=A0all=C2=A0or=C2=A0nothing=C2=A0app=
roach:=C2=A0since=C2=A0we=C2=A0grant=C2=A0any=C2=A0permission =0Athat=C2=A0=
a=C2=A0(authenticated)=C2=A0service=C2=A0wants,=C2=A0we=C2=A0might=C2=A0equ=
ally=C2=A0grant=C2=A0it =0A"AllPermission"=C2=A0=0A=0A<COMMENT>=0AThis is t=
rue, so the codebase perms should be limited to properties and other compil=
e time / static concerns. =C2=A0Like applets, a service proxy is granted permission by the framwork to connect to the=
 originatong service and codebase hosts, however if a service proxy require=
s permissions to contact additional hosts, eg a database for example, it wi=
ll require additional dynamic permissions. =C2=A0So there's a gap, as clien=
t configuration may not always be a suitable mechanism. =C2=A0=0A=0AAs ment=
ioned secure discovery providers I've written also dynamically grant Downlo=
adPermission and DeserializationPermission but only after successful authen=
tication of the lookup service. =C2=A0I have similar mechanisms for service=
s found in lookup results, where services are authenticated before proxy's =
and Entry's are downloaded and deserialized.=C2=A0=0A=0ASo all the above ar=
e basically codebase permissions, granted at various stages, but only as an=
d where necessary in order to proceed through trust establishment between c=
lient and service, without exposing either party to DOS.=0A=0AThis only add=
resses part of the problem.=0A=0A</COMMENT>=0A=0AWhat=C2=A0is=C2=A0needed=
=C2=A0is=C2=A0a=C2=A0way=C2=A0to=C2=A0dynamically=C2=A0decide=C2=A0what=C2=A0permissions=C2=A0are=C2=A0granted =
=0Ato=C2=A0a=C2=A0downloaded=C2=A0"object". =0AThe=C2=A0word=C2=A0"object"=
=C2=A0is=C2=A0again=C2=A0tricky.=C2=A0Today=C2=A0permissions=C2=A0are=C2=A0=
granted=C2=A0to =0A"codebases"=C2=A0-=C2=A0meaning=C2=A0we=C2=A0have=C2=A0n=
o=C2=A0way=C2=A0of=C2=A0separating=C2=A0objects=C2=A0that=C2=A0share =0Acod=
ebases=C2=A0(which=C2=A0is=C2=A0a=C2=A0common=C2=A0thing=C2=A0when=C2=A0usi=
ng=C2=A0Maven=C2=A0repositories=C2=A0as=C2=A0code =0Aservers). =0A=0A<COMME=
NT>=0AVery good point, if we separate downloading from class loading, we co=
uld separate service instances, so they have different static fields (state=
) and separate identity. =C2=A0To do this will require a Maven codebase uri=
 that contains both the codebase and server identity. This is important, ot=
herwise it isn't possible to tell the difference between proxy identity.=0A=
</COMMENT>=0A=0AProper=C2=A0separation=C2=A0of=C2=A0"trust=C2=A0domains"=C2=
=A0in=C2=A0a=C2=A0single=C2=A0virtual=C2=A0machine=C2=A0is =0Adifficult=C2=
=A0(and=C2=A0the=C2=A0good=C2=A0question=C2=A0is=C2=A0really=C2=A0whether=
=C2=A0it=C2=A0is=C2=A0feasible=C2=A0at=C2=A0all=C2=A0to =0Ado=C2=A0properly=
=C2=A0using=C2=A0current=C2=A0Java=C2=A0security=C2=A0model).=C2=A0=0A=0A<C=
OMMENT>=0ATypically after the client is authenticated, the client=E2=80=99s subject is used to determine and inject "user permissions", but only the c=
odebase represents the server identity.=0A=0AProvided sharing is minimal, s=
uch that only service api is shared, then proxy implementations can remain =
private, in which case they can be separated into separate class loaders, i=
nvisible to client or other proxy's other than via service api's.=C2=A0=0A<=
/COMMENT>=0A=0AOf=C2=A0course=C2=A0-=C2=A0eliminating=C2=A0dynamic=C2=A0cod=
e=C2=A0downloading=C2=A0solves=C2=A0those=C2=A0issues=C2=A0-=C2=A0but =0AI=
=C2=A0would=C2=A0say=C2=A0without=C2=A0dynamic=C2=A0code=C2=A0downloading=
=C2=A0there=C2=A0is=C2=A0no=C2=A0point=C2=A0in=C2=A0using =0ARiver=C2=A0:) =
=0A=0AIMHO=C2=A0any=C2=A0discussions=C2=A0and=C2=A0changes=C2=A0that=C2=A0d=
o=C2=A0not=C2=A0solve=C2=A0the=C2=A0fundamental=C2=A0issues =0Afaced=C2=A0w=
hen=C2=A0dynamically=C2=A0downloading=C2=A0code=C2=A0are=C2=A0really=C2=A0m=
oot=C2=A0-=C2=A0they=C2=A0just=C2=A0mask =0Athe=C2=A0underlying=C2=A0proble=
ms=C2=A0which=C2=A0are=C2=A0going=C2=A0to=C2=A0come=C2=A0out=C2=A0sooner=C2=
=A0or=C2=A0later. =0AAnd=C2=A0right=C2=A0now=C2=A0the=C2=A0architecture=C2=
=A0is=C2=A0fundamentally=C2=A0broken=C2=A0because=C2=A0of: =0A-=C2=A0hierar=
chical=C2=A0class=C2=A0loaders =0A-=C2=A0untrusted=C2=A0code=C2=A0execution=
=C2=A0(which=C2=A0Peter=C2=A0is=C2=A0working=C2=A0on) =0A-=C2=A0not=C2=A0fl=
exible=C2=A0enough=C2=A0security=C2=A0model =0A=0A>>=C2=A05.=C2=A0DownloadPermission=C2=A0automatically=C2=A0gran=
ted=C2=A0to=C2=A0authenticated=C2=A0registrars =0A(to=C2=A0signer=C2=A0and=
=C2=A0url,=C2=A0very=C2=A0specific)=C2=A0during=C2=A0multicast=C2=A0discove=
ry. =0A=0AIMHO=C2=A0security=C2=A0model=C2=A0should=C2=A0be=C2=A0orthogonal=
=C2=A0to=C2=A0any=C2=A0other=C2=A0functionality =0A(service=C2=A0discovery=
=C2=A0being=C2=A0a=C2=A0specific=C2=A0example)=C2=A0-=C2=A0so=C2=A0any=C2=
=A0security=C2=A0related=C2=A0code =0Ashould=C2=A0have=C2=A0absolutely=C2=
=A0no=C2=A0knowledge=C2=A0whatsoever=C2=A0about =0A-=C2=A0the=C2=A0interfac=
es=C2=A0implemented=C2=A0by=C2=A0a=C2=A0particular=C2=A0downloaded=C2=A0cla=
ss=C2=A0=0A<COMMENT>=0AThis is the reason I've avoided white listing, inste=
ad download and deserialization=C2=A0 permissions are granted to the codeba=
se uri and Signer of the codebase only.=0A</COMMENT>=0A-=C2=A0any=C2=A0netw=
ork=C2=A0protocols=C2=A0used=C2=A0to=C2=A0implement=C2=A0discovery =0A-=C2=
=A0the=C2=A0concept=C2=A0of=C2=A0a=C2=A0"discovery" =0A<COMMENT>=0AI've man=
aged to keep these concerns separate, security doesn't have any knowledge o=
r responsibility of discovery, rather disco providers request the security =
infrastructure to dynamically grant the permissions required to proceed thr=
ough the next stage of discovery, but only if the provider's underlying protocol authenticates the service host=
=0A</COMMENT>=0AMy=C2=A0two=C2=A0cents.=C2=A0=0A=0AThanks, =0AMichal =0A=
=0AThanks for your thoughts, good to see others considering these issues.=
=0A=0ACheers,=0A=0APeter.=0A=0APeter=C2=A0<jini@zeus.net.au> =0AJuly=C2=A02=
6,=C2=A02016=C2=A0at=C2=A02:58=C2=A0AM =0ANote=C2=A0the=C2=A0comment=C2=A0a=
bout=C2=A0security=C2=A0on=C2=A0the=C2=A0blog? =0A=0ASteps=C2=A0I've=C2=A0t=
aken=C2=A0to=C2=A0simplify=C2=A0security=C2=A0(that=C2=A0could=C2=A0also=C2=
=A0be=C2=A0adopted=C2=A0by=C2=A0river): =0A1.=C2=A0Deprecate=C2=A0proxy=C2=
=A0trust,=C2=A0replace=C2=A0with=C2=A0authenticate=C2=A0service=C2=A0prior=
=C2=A0to =0Aobtaining=C2=A0proxy. =0A2.=C2=A0proxy=C2=A0codebase=C2=A0jars=
=C2=A0contain=C2=A0a=C2=A0list=C2=A0of=C2=A0requested=C2=A0permissions=C2=
=A0to=C2=A0be =0Agranted=C2=A0to=C2=A0the=C2=A0jar=C2=A0signer=C2=A0and=C2=
=A0url=C2=A0(client=C2=A0need=C2=A0not=C2=A0know=C2=A0in=C2=A0advance). =0A=
3.=C2=A0Policy=C2=A0file=C2=A0generation,=C2=A0least=C2=A0privilege=C2=A0pr=
inciples=C2=A0(need=C2=A0to=C2=A0set=C2=A0up =0Acommand=C2=A0line=C2=A0base=
d=C2=A0output=C2=A0for=C2=A0admin=C2=A0verification=C2=A0of=C2=A0each=C2=A0=
permission=C2=A0during =0Apolicy=C2=A0generation). =0A4=C2=A0Input=C2=A0val=
idation=C2=A0for=C2=A0serialization. =0A5.=C2=A0DownloadPermission=C2=A0aut=
omatically=C2=A0granted=C2=A0to=C2=A0authenticated=C2=A0registrars=C2=A0(to=
 =0Asigner=C2=A0and=C2=A0url,=C2=A0very=C2=A0specific)=C2=A0during=C2=A0multicast=C2=A0discovery. =0A=0ANeed=C2=A0to=C2=A0mo=
re=C2=A0work=C2=A0around=C2=A0simplification=C2=A0of=C2=A0certificate=C2=A0=
management. =0A=0ARegards, =0A=0APeter. =0ASent=C2=A0from=C2=A0my=C2=A0Sams=
ung=C2=A0device. =0A=0A=C2=A0=C2=A0Include=C2=A0original=C2=A0message =0A--=
--=C2=A0Original=C2=A0message=C2=A0---- =0AFrom:=C2=A0Peter=C2=A0<jini@zeus=
net.au>=C2=A0<jini@zeus.net.au> =0ASent:=C2=A026/07/2016=C2=A010:27:59=C2=
=A0am =0ATo:=C2=A0dev@river.apache.org=C2=A0<dev@river.apache.org>=C2=A0<de=
v@river.apache.org> =0ASubject:=C2=A0another=C2=A0interesting=C2=A0link =0A=
=0Ahttps://blogs.oracle.com/hinkmond/entry/jini_iot_edition_connecting_the =
=0A=0A=0ASent=C2=A0from=C2=A0my=C2=A0Samsung=C2=A0device. =0A=0A=0A=0A=0A=
=0A

--8323328-712294642-1469956801=:1280--