Radovan Semančík's Weblog

I like Sun. I like Sun Software. They have some really good products. But I hate their support.

More than two weeks ago I had a problem. I was deploying an application to Sun Java System Application Server. And the application crashed. I've done a lot of investigation and found the problem. Strangely, the problem was here:

  String initCtxProviderUrl = "iiop://myserver:3700/";
  Hashtable props = new Hashtable();
  props.put("java.naming.factory.initial",
            "com.sun.jndi.cosnaming.CNCtxFactory");
  props.put("java.naming.provider.url", initCtxProviderUrl);
  Context initCtx = new InitialContext(props);

This is basic. This snippet of code is in any EJB example. It have to work. Anytime. And it works on five other servers in the same environment. But it does not in one particular case. Throws NullPointerException.

I did all the usual diagnosing, turned on debugging, went through logs, separated the problematic code from the rest of the application, used packet sniffer to make sure no firewall is blocking that ... all the usual things. The problem seems to be that a second IIOP listener tries to start when there is already one running. Simple. It took only few hours on Friday night.

As we did not have enogh time to spend on this problem (project schedule), I logged that problem to the Sun On-line Support Center. That was not easy in itself, as the support contract is for the customer and the processes are not always easy. One way or another, the problem report got there few days later.

And the result is ... nothing. No response. For nearly two weeks.

The server lies there, useless. I've done everything I could. I'm not the kind of engineer that bothers to log any minor problem that I could fix myself. Even a full day of my effort is worth it, if I could fix it. And sometimes I invest few days of my time. I see it as a battle, the problem on one side, me on the other. I take it prosonally. I log only the most difficult problems, and only if I end up in the dead end. That's the reason I get angry by such an approach of the support team.

Few weeks before that case I've got another problem. I was testing a prototype to validate my architectural decisions. I was using TinyRadius Java library to make a very simple RADIUS accounting server. All the tests went well. As I was preparing a test report I've realized that I forgot to set a shared secret. The tests should fail. I investigated that and I've found out that TinyRadius library does not implement RADIUS accounting authenticators. I've mailed description of this problem to TinyRadius' maintainer Matthias Wuttke. It was Friday afternoon again. We exchanged few e-mails, Matthias accepted that as a bug and expressed hope that he will be able to fix it soon.

I was really surprised to find a new version of TinyRadius in my mailbox the very same day. It took only few hours to write a fix. And it worked. As I tested it, I've found another problem in the library and Matthias fixed in few hours again. That's great. That's really wonderful. This can make a humble engineer very happy.

This is not my first bad experience with commercial support. I have similar stories to tell about HP, IBM, SAP and even worse for Oracle. And this is not my first good experience with Open Source community. Most problems in open source software can be fixed by searching mailing lists. Most of the bugs are already fixed in the development version or the fix will get there in few days after I report it. And all other problems I can usually fix (or "workaround") myself in few hours or days.

I wonder how will all this end. The level of commercial support goes down. The level of open source community support goes up. Does it mean that we will see dramatic changes sometime soon?

I would really like that change, I think.

Kim Cameron and Aldo Castañeda had a discussion about InfoCards and Higgins that touched the user interface issues (quoting Aldo):

For those who haven't seen an InfoCard demo, one impressive aspect of how it works is that when an "ID transaction" is initiated the system visually and technically goes in to a type of "security zone". To be dramatic envision the lights dimming and the sound of cold steel rolling followed by the clang and reverb of metal meeting metal as the doors close around you. I should stress that in this scenario, unlike the movies those doors are closing to provide a security cordon in service for end-users to keep the thieves at bay not to capture them in act. The point I'm getting at is, that because the end-user is entering a separate "zone" it really shouldn't matter if the end-user entered it through Windows, Linux, Sun or the Apple OS as long as their entry is valid.

I have to say that such a "zone" is not very secure and I doubt it can be made really secure in soon future. The people that ever worked with "Orange Book" systems knows why, for all of the others here comes the explanation:

As you start an "ID transaction" in InfoCards, the screen will dim and a big window appears that allows you to choose a "card". You choose a card, enter some password or PIN to unlock it and proceed with transaction. Looks fine, looks secure. But ...

The whole Windows screen can be easily used by any application, like screen saver or a computer game. Now imagine a trojan that takes whole Windows screen and simulate the "dimming" effect of InfoCards secure zone. I bet you will go on and enter the PIN or password to the trojan.

Offtopic: This trick is really old. I remeber how we used it back in the university on old back-green text terminals, simulating UNIX login prompt.

Well, it may not be that easy in the practice. The trojan will need to learn what cards you have in your InfoCards system (I suppose that the "common" application will not have access to full InfoCards API). The easiest way to do it is a wild guess. The user may not notice that some card is missing or that other is slightly different. When I consider how successful are today's primitive phishing attemps, I can believe that simple guess may be a worthy technique. Then there are plenty of processes in Windows that have high privileges. Subverting any of these may provide access to full InfoCards API for the trojan. And there may even be the easiest way of all. Many windows users are administrators of their own computers. What else the trojan needs?

How to solve the problem? That's not difficult. The designers of "trusted" systems solved that long time ago. The solution is called "trusted path". You need to have a portion of a screen that no OS application can write to. You need to have a button in this portion of a screen that no OS application can override. And the user will use that button to switch to the secure mode. No trojan can subvert that, unless it already has god-like privileges. I got it that the same reason was behind the infamous ctrl-alt-del combination in Windows, but it looks like the motives are already forgotten.

But for that to work the OS has to be at least a bit secure. At least some parts of it (like OS core and window manager) has to be trustworthy. And we still have a long way to get to that state - for all common desktop OSes (including Linux). Maybe NGSCB (read "Palladium") and similar projects can bring this as a side effect? I doubt it ... but hope dies last ...

I've just got a notice that my contribution was accepted for InfoSeCon 2006 conference. The paper provides an overview and perspectives of Identity Management technologies in enterprise, Internet (user-centric) and government areas. I've decided to put toghether such a "overview" paper as the most appropriate for intended audience.

I want to thank the conference organizers for choosing such a great location. Conference venue - Cavtat is located on one of the nicest coastlines of the world. I just can't resist the beauty of "Jadran", the Adriatic sea coastline in Croatia and Montenegro. I invite all of you to see it for youself.

All of you that plan to attend the conference, please let me know that you will be there. We could meet and have a talk there. Just leave a comment here or contact me directly.