An example of trusted subsystem fail in meatspace

Here I am, stuck in Sydney airport for various cascade delays but awarded with the Gift of Free WiFi. I am coming back from a awesome 2 weeks in Australia and Nw Zealand, where I met great customers & partners, enjoyed the company of amazing friends & colleagues and drew few chuckles (while hopefully passing some claims knowledge too) from the awesome audiences of #tenz9 and #auteched. BTW, thank you for the fantastic feedbacks!

I should really take advantage of any free minute for working on the book, but having woken up at 2:45am I don’t feel especially intelligent (if ever) and I’d do more damage than good: hence I’ll just spend 1/2 hour reinforcing one topic that was especially popular during the techeds, the argument against trusted subsystems.

Case on point. TechEd New Zealand took place in the same hotel where the speakers were staying. The event level was directly connected to the rooms via handy elevator, but unfortunately they were not accessible:

Or at least, that’s what the black tape and the sign would want you to believe.

However, if you’d be rebellious enough (I believe the technical term is “polarity responder”) and if you’d be so bold to hit the call button anyway… surprise! You’d get the familiar “pling!” of the elevator and one cabin would materialize at the floor.

Now, you can think of this button-tape-signs contraption as the frontend of the application “go to your room”. This application tries to keep everybody out, apart from the service people who indeed know that the elevator works perfectly. It is not a very secure way of protecting a resource, but the intent is clearly that one. So, if the only line of defense would be this, or in other words the elevator cabin would live in a trusted subsystem, then the security of the solution would be very, very ineffective.

In fact, it turns out it’s not the case. Even if you “hacked” the system by clicking the button anyway and went around the tape, clicking on the floor buttons would not do you any good: it turns out that you need a room key for accessing your floor.

So that’s not too bad after all, but it could have been :-)

Note. This example does not map 1:1 with what we discussed in the sessions, since here there’s no delegation (I am using the room key directly, there’s no actor that pushes buttons on my behalf), however hopefully that gives you (if necessary) the feeling of why it is a good idea to make access checks at the resource and on actual user privileges instead of expecting that the frontend security will always enforce the right thing :-)