Hey Endre, (Also CC akka-dev as I realised this type of low level stuff probably fits in a lot better there..)
On Thursday, 28 August 2014 20:08:09 UTC+10, Akka Team wrote: > > 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. > Cool > > >> >> - 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 > That's good to know for ActorRef's. I hadn't even considered manually forging one, so definitely a potential pain point. Is there currently a size limit that would make it impractical to use a longer (128/256 bit) random id (maybe trying to fit into a certain packet length/etc)? I would assume it would increase the overhead somewhat for remoting purposes, and memory usage locally? > >> - 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. > > *nods* I'm aware of the trusted-selection-paths part of Remoting, though what I was after was how the 'deep' parts of selection work (behind the scenes, in the dungeon where dragons sleep and users fear to tread) For an ActorSelection path of `/a/b/c`, does the 'selection message' have to pass through A, B and finally reach C? Or is there some sidechannel lookup that once it hits the ActorSystem, it figures out how to directly talk to C's ActorRef/etc? Similarly, for a wildcard ActorSelection of `/a/b/*`, does it first pass through A to B, and then B broadcasts to all of it's child actors? (Or again, some kind of sidechannel lookup?) > >> - 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. > I realise this is getting deep into the core and shouldn't be overridable by normal users/actors (here there be dragons), but the fact that Remoting manages to intercept messages (by somehow modifying/filtering things before they get to the 'normal' ActorCell implies that it must be possible somehow. Obviously you could fork/hack the core to make the changes, but given the modular nature of Akka I wonder if it couldn't be achieved somehow through modules/overloading/mixing in traits/etc. > > >> >> - 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. > *nods* Fair enough. > >> 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. > Understandable. To be honest the way i'm approaching this thought experiment is that it would potentially start as a fork/etc, but designed in such a way that it could be merged back into core if/when it's figured out properly. And in doing so, would be easily kept up to date with the everchanging internals. > > 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. > Definitely sounds like a good start. That was my original theory (protect the ActorRef protect the Actor). Depending on how ActorSelection works (see above) I can think of one potential way to implement that side of it. Yeah, definitely not a perfect solution (a determined attacker will always break in, regardless of what you do, the idea is to make it hard enough that they don't want to/it's impractical), but a stepping stone in the right direction. Things like reflection/etc would be a whole nother level of things (though one that I don't think is necessarily required for the most basic use case: potentially untrusted remote ActorSystem sending messages in) - Glenn / devalias > > -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 < >>>>> 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/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 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. >>>> 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.
