Hi Glenn,
On Tue, Aug 26, 2014 at 2:03 AM, Glenn / devalias <glenn.gr...@wlpc.com.au>
wrote:
> That makes sense.
>
> By that regard, it would have to be assumed that you wouldn't ever
> recommend exposing a remoting enabled system to an untrusted network (eg.
> internet)? Is it common/best practice to isolate an akka system/cluster
> from potentially untrusted clients through abstraction layers/etc?
>
There is a difference between protecting from untrusted members to connect,
and protecting from connected untrusted members. You can use SSL with
remoting to achieve the first, so that only trusted systems can connect
through remoting to your system.
>
> Is it that you believe the system isn't robust enough to handle a
> potentially malicious communicator, or is it just a general level of
> healthy paranoia/defense in depth?
>
To be honest, untrusted connected peers were not a design goal, so we never
really audited how robust it is to malicious peers. I would not say it is
secure until it has been reviewed by someone with extensive security
background.
>
> It would seem to me that theres no practical reason remoting couldn't
> support enough security to be exposed directly (obviously with the always
> present risk of unknown bugs/etc, and the time that would be required to
> actually implement/secure it) Furthermore, I would imagine there are a lot
> of potential usecases where it would make a lot of sense. Obviously you
> could abstract those use cases using REST/direct sockets/etc, but it seems
> like that would involve extra effort/layer of abstraction, where you might
> actually benefit from using akka directly.
>
Yes, it would be nice to have this feature, I agree on that.
-Endre
>
> Cheers
>
> Glenn / devalias
>
> On Monday, 25 August 2014 20:27:48 UTC+10, Akka Team wrote:
>
>> Hi Glenn,
>>
>>
>> On Mon, Aug 25, 2014 at 8:12 AM, Glenn / devalias <glenn...@wlpc.com.au>
>> wrote:
>>
>>> I realise this thread is almost 2 years old, but it's because of that
>>> that I was wondering whether the design patterns within still hold true.
>>>
>>> Given UntrustedMode blocks remote deployment, PotentiallyHarmful
>>> messages and it prevents actor selection outside of the whitelisted
>>> 'receptionists', it seems to me as though this would be a reasonably safe
>>> model for communication with a potentially untrusted client ActorSystem.
>>>
>>> The docs still mention a locked down guardian 'remoting' ActorSystem,
>>> with a local 'protected' ActorSystem behind it, though the only reason I
>>> can think of that this would need to be the case is to prevent the
>>> accidental leakage of a 'protected ActorRef' to an untrusted client, since
>>> they could then potentially forge messages to the 'protected' system/bypass
>>> the receptionist/selection protection/etc.
>>>
>>> Is anyone able to confirm/deny this for me?
>>>
>>
>> Remoting is designed to connect systems where at least a reasonable level
>> of trust is expected and this excludes malicious behavior. The features
>> above are a way to avoid certain mistakes, but not enough for preventing
>> attackers to do harm. If you need to connect untrusted systems you should
>> use a different, controlled interface, for example a REST API layer (with
>> Spray or Play for example) or use ordinary Tcp client/server approaches
>> (you can use akka IO for that purpose).
>>
>> -Endre
>>
>>
>>>
>>> Also, as an aside, has anyone come across a 'sandboxed actor' pattern
>>> (to prevent actors that are children of the 'sandbox guardian' from being
>>> able to select actors that are 'above'/parents to it, prevent
>>> PossiblyHarmful messages that would shutdown the ActorSystem, etc)
>>>
>>> Cheers
>>>
>>> Glenn / devalias
>>>
>>>
>>> On Friday, 28 September 2012 20:34:58 UTC+10, √ wrote:
>>>
>>>> Roland also suggest putting the sensitive ActorSystem "behind" a
>>>> front-ActorSystem which is really tied down, so you do the
>>>> authentication/authorization there.
>>>>
>>>> Cheers,
>>>> √
>>>>
>>>> On Fri, Sep 28, 2012 at 1:30 AM, √iktor Ҡlang <viktor...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Pete,
>>>>>
>>>>> the point of akka-remote is to provide scaling-out facilities and is
>>>>> as such based on a peer-to-peer mode where each node is considered to be
>>>>> trusted.
>>>>>
>>>>> It is definitely possible to implement your own security checks in
>>>>> your own custom RemoteTransport.
>>>>>
>>>>> Having said that though, I think you're right in the sense that
>>>>> untrustedMode should not allow deployments.
>>>>> I'll open a ticket to fix that.
>>>>>
>>>>> Cheers,
>>>>> √
>>>>>
>>>>>
>>>>> On Thu, Sep 27, 2012 at 8:19 PM, Frost <pete....@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I would like to use akka to set up a client server architecture where
>>>>>> user facing client applications run akka locally and connect to the
>>>>>> server
>>>>>> with remote actor references. However, it appears that when you use
>>>>>> akka-remote, the server becomes very insecure. For instance, you can
>>>>>> connect with a client and have it deploy an actor which runs remotely on
>>>>>> the server. I have tried constraining this using configuration settings
>>>>>> (see below), but they don't stop this from occurring. Ideally, I would
>>>>>> there would be some way of turning this off completely.
>>>>>>
>>>>>> It would also be nice if you could limit access to a set of
>>>>>> "published" actor references, otherwise clients could access actors which
>>>>>> were meant for internal use only, which is not ideal.
>>>>>>
>>>>>> It would be preferable if there were some sort of
>>>>>> authentication/authorization for remote actor systems that could be
>>>>>> applied
>>>>>> on an ActorRef by ActorRef basis to constrain access to any given actor
>>>>>> by
>>>>>> looking at the remote actor systems credentials to see if it is
>>>>>> authorized.
>>>>>> If this information were exposed to the actors themselves, then they
>>>>>> could
>>>>>> also use this information when determining how to respond to individual
>>>>>> messages.
>>>>>>
>>>>>> I don't currently see any way to do any of this, which leads me to
>>>>>> believe that I will have to disable akka-remote, and then wrap the client
>>>>>> and server actor systems in a custom networking protocol which will let
>>>>>> me
>>>>>> marshal the messages back and forth between the actor systems using some
>>>>>> sort of custom security implementation. Having to do this seems to
>>>>>> defeat
>>>>>> the point of having a module like akka-remote. It also makes using the
>>>>>> akka platform a much harder sell to my boss(es).
>>>>>>
>>>>>> It was really great how simple it is to setup remote actors and start
>>>>>> passing messages around with minimal/no fuss configuration...
>>>>>>
>>>>>> Some of the things I tried in my configurations:
>>>>>>
>>>>>> (in server's conf file)
>>>>>> akka.remote {
>>>>>> untrusted-mode = on
>>>>>> netty {
>>>>>> require-cookie = on
>>>>>> secure-cookie = "a cookie for testing"
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> (in client's conf file)
>>>>>> akka.actor.deployment {
>>>>>> /onserver {
>>>>>> remote = "akka://Server@127.0.0.1:2552"
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Please note, I tried this without the cookie's enabled as well as
>>>>>> some other combinations.
>>>>>>
>>>>>> I would have expected the untrusted-mode to block the local
>>>>>> deployment of an actor from a remote actor system, but it does not.
>>>>>>
>>>>>> Thanks in advance
>>>>>>
>>>>>> --
>>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>>>>> p/akka-user
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Akka User List" group.
>>>>>> To post to this group, send email to akka...@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to akka-user+...@
>>>>>> googlegroups.com.
>>>>>>
>>>>>> Visit this group at http://groups.google.com/group/akka-user?hl=en.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Viktor Klang
>>>>>
>>>>> Akka Tech Lead
>>>>> Typesafe <http://www.typesafe.com/> - The software stack for
>>>>> applications that scale
>>>>>
>>>>> Twitter: @viktorklang
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Viktor Klang
>>>>
>>>> Akka Tech Lead
>>>> Typesafe <http://www.typesafe.com/> - The software stack for
>>>> applications that scale
>>>>
>>>> Twitter: @viktorklang
>>>>
>>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/
>>> current/additional/faq.html
>>>
>>> >>>>>>>>>> Search the archives: https://groups.google.com/
>>> group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>>
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Akka Team
>> Typesafe - The software stack for applications that scale
>> Blog: letitcrash.com
>> Twitter: @akkateam
>>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
--
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
