Security Issues The RMI Registry

also begun including a line of text. Here, for example, is an entry from the yellow pages for Mountain View, California: AQC: Air Quality Control Inc. Cleaning and Decontamination Services 1-800-433-7117 Topics A topic is a logical grouping of entries according to similarity of goods or services provided by the entries. For example, Cleaners is a topic. Topics have only one property: an empty topic can refer you to another topic. Thus, for example, the following topic is empty in my local yellow pages: Swing Sets See: Playground Equipment Unlike directories, which can be nested, topics dont contain other topics. Instead, topics are ordered alphabetically, to make it easier for a human being to search the yellow pages.

14.5.1.3 The general idea of directories and entries

Whats good enough for the yellow pages and filesystems is most likely good enough for a naming service. That is, naming services for distributed applications usually consist of two basic abstractions: Entries An entry is a name, a set of name-value pairs, and enough information to construct a stub. Contexts A context [ 3] is analogous to a directory or a topic. It contains other contexts, and entries as well. Contexts are named and are often allowed to have properties. In addition, there is usually a single base context from which all entries can be reached, either directly or by accessing a context contained in the base context. [ 3] The word context is, unfortunately, the standard term. In addition, we need to define the idea of a logical name. A logical name is neither an entry nor a context. It consists of the following information, rendered in a suitable format: • The machine running the naming service containing the base context and the port to which the server listens • A set of context names that form a path e.g., the first name in the path is the name of a context contained in the base context, the second name in the path is the name of a context contained in the first context, and so on • An entry name In Chapt er 15 , when we build a naming service to replace the RMI registry, we will implement this sort of hierarchical structure.

14.6 Security Issues

The last thing we need to discuss about the RMI registry involves security. The archetypal bad case is something like the following: A hacker has written a program that scans the Internet looking for RMI registries. It does this by simply trying to connect to every port on every machine it finds. Whenever the program finds a running RMI registry, the program immediately uses the list method to find the names of all the servers running on the registry. After which, the program calls rebind and replaces each stub in the registry with a stub that points to his server. The point: if you dont restrict access to a naming service, then your network becomes incredibly vulnerable. Even if each individual server is secure e.g., each individual server requires the clients to log in, the naming service itself is a vulnerable point and needs to be protected. The solution the RMI registry adopted was quite simple: any call that binds a server into the registry must originate from a process that runs on the same machine as the registry. This doesnt prevent hackers from finding out which servers are running, or calling methods on a given server, but it does prevent them from replacing any of the servers, and thus prevents them from altering the structure of client-server applications, which depend on the registry.

Chapter 15. Naming Services

In Chapt er 14 , we discussed the RMI registry. In this chapter, well build on that discussion to explore naming services in general. The goal of the chapter is to help you understand just what a naming service is, and how theyre used in distributed computing. Well also implement a new and more flexible naming service. As part of doing so, well discuss threading and bootstrapping issues again, this time from an applied perspective. And finally, Ill introduce an important design technique known as federation. By the end of this chapter, youll have a much better understanding of naming services and of how to build multithreaded servers. Naming services have a long and varied history in distributed computing. Examples of modern naming services include: The Domain Name System DNS This is how the Internet resolves logical names such as www.oreilly.com into IP addresses. Because it is used everywhere, and must handle extraordinary loads, DNS is a very simple protocol with limited query functionality. But it does map logical names to IP addresses and is, more or less, the definitive example of a naming service. The Lightweight Directory Access Protocol LDAP This is a protocol and API definition developed at the University of Michigan. It is commonly used in large enterprises for authentication e.g, for storing information about employees in a way thats easily accessed by computer applications. The COSNaming Service This is defined as part of the Common Object Request Broker Architecture CORBA standard. CORBA is a specification for building cross-language distributed systems. That is, CORBA implementations are frameworks used to build a certain type of distributed application. And, as such, CORBA requires a naming service to solve the bootstrapping problem. These three examples define three distinct points on the performanceflexibility curve. DNS is the most limited. It can resolve names to IP addresses but nothing else, and it doesnt support any advanced query capabilities at all. LDAP has extensive support for attributes. However, it doesnt really support the idea of storing servers, or stubs to servers. Instead, its intended to support fast queries for predefined records, such as static data structures. Cameron Laird in Sunworld, July 1999, Lighting up LDAP: A programmers guide to directory development, Part 1 gave the following motivating example for LDAP: