Thanks for the insight :) It would definitely be cool if there was some more flexibility/option for hooking security features in 3.x
Cheers - Glenn / devalias On Friday, 29 August 2014 20:27:26 UTC+10, Akka Team wrote: > > Hi Glenn, > > > 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? >> > > Yes, and it would slow down the equals method on ActorRef (since the ID is > currently an Int it is fine, but going above 64 bits would mean traversing > an array). This current ID scheme was designed to disambiguate between > different actors occupying the same path. For example an actor with ref > /user/a/b#1 (the id field is 1) will remain accessible through the same > ref, even if it has been restarted multiple times. But if that actor is > stopped and then a new one created on the same path it would have a > different id, for example /user/a/b#2. So the 32 bits where enough for that > purpose. > > I am not sure what the real overhead would be with 128 bits, but it might > be minimal, we just need to measure. > > >> >> >> *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? >> > > In the original implementation it had to pass A and B to reach C. That was > quite slow, and therefore we replaced with an approach that looks up the > target in the internal supporting structures and sends the message as > directly as possible (but we still have the traversal part , too, for > wildcards). > > >> >> 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?) >> > > I have to verify in the code, but if I recall correctly it goes directly > to B first, but then on it is broadcasted downwards. > > >> >> 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. >> > > Remoting is in a special position, since all messages must come through > the Socket which it can filter as much as it desires. On the other hand > "tell" directly writes to the mailbox of the destination actor in the local > case. So when you write > > b ! "hello" > > Then it doesn't go through any central point but enqueued to b directly. > > >> >> >> 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. >> > > Since all of these changes would be breaking, they cannot go into the 2.x > line anymore, they would need to wait until Akka 3. There will be an > official roadmap produced soon, please refer to that for timing details. > > > 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) >> > > Assuming that the attacker cannot run code in your JVM the only point you > really need to protect what actorRef is exposed to what other modules and > make it impossible to forge actorrefs through remoting (writing Akka > protocol packets directly) and have a whitelist as well. > > We are currently not focused on such work, but it might be possible to add > some minor changes in Akka 3 (like larger ID fields and certain pluggable > points) that can enable more security in-depth features. > > -Endre > > >> >> - 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 < >>>>>>> [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/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] <javascript:>. >> To post to this group, send email to [email protected] >> <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 [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.
