Hi Glenn,
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? > > Yes, almost everything, but there are exceptions here and there. > > - 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? > > An ActorRef is basically analogous to an IP address on a network. Once you know that address you can send packets to that node, and in Akka if you know the ActorRef you can send messages to that actor. Unlike networks though, Actors do not have firewalls :) There is one feature of ActorRefs though that it uses a 32 bit random ID at the end of the path. Without knowing that you cannot send messages directly (except via ActorSelection). This is not enough for security though since that 32 bits are not enough, and they are not generated by a cryptographically strong PRNG. > > - 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) > > ActorSelection work with paths, whenever you know a path, you can send a message to it. Also there are wildcards, so ActorSelection basically makes all actors accessible. In the case of remoting there is a setting, "akka.remote.trusted-selection-paths" that can be used as a whitelist -- which paths are allowed to be addressed via ActorSelection remotely. Oherwise, there is not much isolation between actors in a local system. > > - 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 is not possible to override them, and this is very internal stuff -- the "dungeon" so should not be accessible to users. If you configure remoting with "use-untrusted-mode" that means it will not accept many of these kind of messages (subclasses of PossiblyHarmful for example PoisonPill). This is just a lightweight feature not security in-depth. Also it only isolates remote nodes, but not local actors. > > - 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?) > > I think it is not possible to achive this without heavily hacking the internals of Akka itself, so you would need to fork it actually. > 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. > The problem is that implementing this would need to depend on internal APIs that we do not necessarily document, keep source or binary compatible along minor versions, etc. So it would be a huge effort to do such thing by anyone. Anyway, a potential experiment might do the following: - strengthen the ID field of ActorRefs, and probably audit messages that go to an existing path, but with wrong IDs - somehow control and limit communication via ActorSelections The above two would basically achieve that without knowing the ActorRef itself it is not possible to send messages to an actor. So you only expose an actors reference to its trusted peers. Of course this would still be incomplete because these actors would be still accessible via reflection, reading internal fields etc. -Endre > > - 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 <[email protected] >>>> > 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 <[email protected]> >>>>>> 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 <[email protected]> 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://[email protected]: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 [email protected]. >>>>>>>> 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/c >>>>> urrent/additional/faq.html >>>>> >>>>> >>>>>>>>>> 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 unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>>> To post to this group, send email to [email protected]. >>>>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
