Re: [JXTA discuss] how to stop malicious peers?

> Matteo Bisi wrote:
>
> >Mohamed Abdelaziz wrote:
> >
> >
> >
> >>A good start would be to use
> >>platform/binding/java/impl/src/net/jxta/impl/access/AccessList.java  to
> >>manage a peer access list, and add a mechanism in all transports to
> >>accept or refuse connections during the welcome message negotiation.
> >>adding it at transport welcome message negotiations avoids any
> >>unnecessary waste of resources.
> >>
> >>
> >
> >Ok, this is useful if the rdv knows that the peer attempting to connect
is
> >(or not) a
> >malicious peer.
> >Suppose, instead, that the rdv doesn't know in advance the real identity
of
> >the peer: in this case the rdv can only monitor peer's activity and, in
some
> >way, understand
> >that the peer is a malicious - after its connection. Can I use the
> >AccessList in this situation?
> >
> >
> >
>
> Yes.  One may implement a policy by which new connections are accepted
> until some form of authentication/acceptance is established, after which
> the access list is updated to accept, reject, or sever a connection from
> a specific peer.

I would develop a secure rdv policy control for my secure group, in which
there are a new MembershipService for peer's authentication and group
admission,
and a new AccessService for managing peers' authorizations.
In this groups, a peer (edge or rdv) can have different 'roles', (e.g. from
the least to the
most important: 'newbie', 'searcher', 'publisher', 'admin').
For each role, a peer can perform only, well-defined, actions.

What I need is a sort of "capabilities"-based access control, so I would be
sure that a peer which is a 'newbie' can not perform unauthorizaded actions.
For this purpose, I think to create a specific access table for each
authenticated peer,
to store the operations it can perform.
In this scenario, there is no centralized table, but instead when a peer is
authenticated, it is
given a number of credential. Each credential is associated with a
particular operation. It is something like having a ring full of keys rather
than a single key.
I suppose to meet this requirements through a specific AccessService
implementation.

The main problem is: an hackered peer can skip the
access control, thus trying to perform unauthorizated actions, and my
AccessService become useless...

To prevent this situation, I want to dispose some further 'check points'
that can block
this wrong attempt. An idea could be: if a rdv (or some admin peers), is
able to check
if a peer which is attempting to perform an action (which involves a
discovery task, such
as 'publishing' or 'discoverying'), has or not the right permissions, it
should block it in some
way.

To do this, I need to modify some JXTA sources and to add a custom rdv
policy
for checking this permissions.
The ACL solution seems good, but it should be updated runtime, so I don't
know if
it is the best choice.

What are the more suitable sources I should modify?
Only the EdgePeerRdvService and the RdvPeerRdvService?
Or should implement a new RendezVousService?

Thank you