Heya,
On Wednesday, 27 August 2014 19:00:45 UTC+10, Akka Team wrote:
>
> Hi Glenn,
>
>
> On Tue, Aug 26, 2014 at 2:03 AM, Glenn / devalias <glenn...@wlpc.com.au
> <javascript:>> 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.
>
Cool, that's definitely useful to keep in mind then :)
>
>> 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.
>
*nods* Coming from a security/pentesting background myself i'd definitely
agree with that. Was more curious as to whether there was a known issue, or
just that it hadn't been exhaustively audited/pentested.
>
>> 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.
>
I was having a bit of a browse around the code for fun the other day with
regards to this part (i'm pretty new to Akka in general, so some of these
parts might be common knowledge/obvious, but bear with me)
- It seems most everything inside akka is communicated with messages
themselves, including things like system.shutdown(), selection etc. Is that
a fair assumption?
- Following on from that, with actor selection eg (/user/A/B/C) it
seemed to me from a quick glance that a message is sent to the 'first'
actor in the path (A), and then it will determine how to send the message
on to the next section (B), etc, until the message finally reaches the
destination. Is that how it works?
- If so, that would allow (for example) a 'sandbox/firewall' type
actor B to decide to drop the selection message/respond with a 'cannot be
found' type message, and therefore 'protect' C from ever being addressed
using selection. Does that sound right?
- How does things like parent selection work? (Eg.
myActor.parent.parent.parent) Does it use ActorRefs only, or is there some
manner of messaging involved to determine it? If messaging, does it use
selection, or another means? (if we know the message it uses then we can
choose to block them in a sandbox)
- It looks like ActorCell (
https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/actor/ActorCell.scala)
contains the bits to handle the automatic framework type messages
(AutoReceivedMessage) and similar in `invoke`, `autoReceiveMessage`,
`receiveSelection`, etc
- Is it possible to override autoReceiveMessage with your own
implementation? And if so, how would someone go about doing that?
- I would guess remoting is a good place to start looking, given
it seems to handle selection messages/etc before they get to the
'inner
core'. But I wonder if that's only achievable because it's blocking
them
before they get to the 'normal' inner routing.
- It looked as though there were some system messages defined in
https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/dispatch/sysmsg/SystemMessage.scala
and
then there were a bunch more messages defined
in
https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/actor/Actor.scala
- Are there any other places 'important' messages are
defined/documented/etc and ideally their use/purpose. Knowing what
messages
exist and their purpose would be an important step in figuring out what
needs to be isolated/protected against, etc.
- My thoughts is that you'd want to end up with something like a
SandboxedActorRef that you could use (so maybe looking a bit closer at how
ActorRef/RemoteActorRef are implemented would help?)
Obviously I don't expect this to be something the core Akka team looks at
any time soon (if ever), but knowing where to start looking/how I could
approach some of the parts would allow me/someone else who's interested to
look at implementing it.
- Glenn / devalias
> -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+...@googlegroups.com <javascript:>.
>> To post to this group, send email to akka...@googlegroups.com
>> <javascript:>.
>> 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.
