Summary
A trailer for the security track at JavaPolis featuring O.S. security semantics in language-based systems, JAAS and auditing.

I put together the security track of JavaPolis 2003, a conference run by the Belgian Java Users Group. In this blog, I look forward to events on December 4^th.

The first three talks are on security audits.

The first speaker, Dirk Dussart, is security consultant at PricewaterhouseCoopers (that's apparently how they spell their name, very Wiki). Dirk has been doing code audits for many years and focuses on the security of Java web applications.

André Mariën is chief scientist at Ubizen, a young Belgian IT security company that has experienced enormous growth in the last few years. I know André from my student days when he was a young assistant at the K.U. Leuven. I guess he was the first geek I ever met. I remember my awe as he optimized assembly code in his seminars on computer architectures. He went on to head the team that wrote what many considered the world's finest Prolog environment.
André's presentation is entitled 'Know Thy Enemy' and provides a classification of security threats. A systematic understanding of possible security flaws is indispensable when you want to check that threats are covered adequately.

Georges Ataya is an independent security expert who founded the post-graduate program on ICT audit and security at the Solvay Business School in Brussels. Georges often advises organizations concerned with protecting themselves against the sloppiness of developers who have created the applications running on their infrastructure. For this talk, he takes the perspective: how can developers ensure that their applications pass their customers' audits?

Frank Piessens teaches secure software engineering and will be talking about the Java Authentication and Authorization Service (JAAS).
Code-based authorization is a well-known feature of Java. It deals with establishing whether code should be trusted and given access to critical resources. The ability to load and execute remote code dynamically caused great excitement when Java burst on the scene in 1995. I remember sceptical colleagues shrugging their shoulders and saying "sounds like a virus". However, such concerns were met by the Java language designers (James Gosling will be giving a keynote BTW) providing a 'sandbox' that isolated untrusted code. The sandbox turned out to be flawed, but more of that later.
The key point is that the classical Java security model does not give access to critical resources on the basis of who is executing the code, but rather on the basis of what code is executing. So, coming to Java security from an operating system perspective, it all seems topsy-turvy, it's as though every program would have its suid bit set. But it makes complete sense in the context of mobile code.
However, the world has changed since applets revolutionized our perspective on the web. Many (the most successful?) Java applications now run on servers in highly secured environments where introducing mobile code is like pissing in the sink - it is just not done. On the other hand, often you want to know on whose behalf code is executing in order to make sure that clients are not accessing out of bounds resources. Just as users should not be able to modify other users' files in the filesystem, online shoppers should not be able to modify each others' shopping trolleys. This is the kind of problem JAAS is set to solve. JAAS was introduced as an optional package in Java 1.3 and became an integral part of the 1.4 release, but still it seems less widely understood than code-based authorization. This is arguably due to lack of exposure. Frank will provide a lucid overview of JAAS.

Dan Wallach revealed a number of vulnerabilities in the original Java sandbox, leading to the realization that the original concept itself was fundamentally flawed. In response, he pioneered what was known as the 'stack inspection' technique. It is in use today, not only in Java, but also in e.g. Microsoft's CLR. In a keynote, Dan tells the story of the discovery of Java security flaws and in how far they have been addressed.
His talk on the security track looks at how language-based systems can be extended with security features that we have come to love and expect in an OS. Notably the notion of isolation is important: when one task misbehaves, it should not compromise other tasks, let alone crash the (virtual) machine. If my own experience is anything to go by, this is very pertinent; it was a central concern with two major customers of mine this year. The easy/standard way of resolving the problem today is to fall back on OS security. This means running tasks in separate VMs. However, the VM overhead costs are incurred several times over, not to mention the additional effort required to set up communication between the tasks that became so separated.
I cannot help feeling that a lot of water will flow to the sea before we learn how to do this right. Dan and his colleagues have made great strides in improving language-based mechanisms and made them more efficient and complete. However, I am uneasy with the duplication of security features in language environments and the OS. This unease may not so much reflect that such duplication is undesirable as the difficulty to get the tradeoff right between which security requirements are taken care of by the language and which can be left to the OS. In other words, while it enriches our palette, it also makes our job more difficult.

If security is your thing, some of the speakers to check out in the other tracks are Eve Maler who will be discussing web services security and Zhiqun Chen on JSR 177 (security and trust services for J2ME). Plenty of great speakers on other topics too.

Hope to see you there.

Talk Back!

Have an opinion? Be the first to post a comment about this weblog entry.

RSS Feed

If you'd like to be notified whenever Johan Peeters adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Johan Peeters is an independent software architect who spends a lot of time plumbing and generally fixing leaks.