Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue Argonne, IL 60439
However, the complicated nature of the operating system and their historical baggage imply that there are numerous bugs that can be exploited by attackers. CIAC works with computer manufacturers to provide fixes for most (but not all) of these attack vectors, but being sure that these patches are applied to all machines on a computer network is an administrator's nightmare. Because a system is only as strong as it's weakest host, machines with security holes can be compromised. Attacks that are carried out from a compromised machine that is inside the local network bypass many of the controls that have already been discussed, and thus are more likely to succeed.
Host machines that are required to perform important security functions should be more resistant to attack than ordinary nodes. Servers for DCE and Kerberos 5 certainly fall into this category. Fortunately, the CMW operating system provides this higher level of assurance. CMW was designed for use by the military to handle multilevel classified data in a manner that would ensure its protection and integrity. The latest generation of CMW systems work well enough that they can now should be exploited for nonmilitary purposes.
CMW achieves its security goals by enforcing Mandatory Access Controls (MAC) which label all files on the system with a security level and compartment(s). In addition the role of the superuser is broken up into about 50 different privileges. All of the usual Unix utility programs (ls, chmod, mount,....) have been rewritten to only assume a privilege when it is needed, and to drop it when it is no longer needed. This is called the Principle of Least Privilege. In addition, by default, users do not have the authorization to run commands such as chown or mount that could be used to provide unauthorized access to data. This effort succeeds. For example, Sun Microsystems claims that none of the CERT/CIAC computer advisories has ever applied to their CMW systems.
One issue that must be resolved is host access to the CMW system. One way CMW systems resist attack is by only communicating with hosts whose ip addresses and security features (multilevel, unlabeled,...) are listed in the secure file M6RHDB. A CMW machine will not even answer a ping from an ip address that is not listed in this file.
In a cross-realm environment, it is the foreign client that contacts the security server presenting a ticket, and asking for another ticket. The two security servers do not communicate directly, they only share a key. They communicate via the client, giving and receiving tickets which are encrypted in the shared key. On a local cell, it might be possible to list all of the clients in the M6RHDB file, but this would be almost impossible to do with foreign clients. A similar situation applies with portable computers which change their ip address according to their location. Thus, we will have to develop a method for allowing non-listed hosts to communicate with the CMW server.
In the first phase of this proposal, we plan to install two CME DCE servers, one at ANL and the other at ORNL. Two servers are required because CMW workstations can only be administered from the console.
In addition to providing resistance to attack, the CMW concept can be used in its own right. The CMW's security labels can be employed to control access to resources by both their sensitivity, and their "need to know." For example, all researcher's on a project should be able to access the project's data files, but perhaps only the leaders should be able to access the financial data. In phase two of this project, we propose to implement these access controls by setting up a DFS server on the CMW host. Access to these files will have to pass the additional MAC authentication of the CMW system. This scheme can provide protection for proprietary data that is much higher than on a conventional Unix system. Given the increasing exposure of government agencies to lawsuits in this area, we believe that these added precautions might prove to be necessary in the near future. CMW hosts might also be an ideal platform for certification authority and public key servers.
Argonne National Laboratory has been operating two DCE test cells, and has been using Kerberos Version 4 and Version 5 for a number of years. Douglas Engert is the Chairman of the ESnet Authentication Task Force, and has been very active in the Kerberos/DCE interoperability activities and in cross-realm authentication testing and design.
Start Date + 6 months:
DCE, hardware, and Kerberos 5 procured and installed with a local cell.
Start Date + 9 months:
System integrated into DICCE cross-realm authentication effort.
Start Date + 15 months:
Multilevel DFS server set up and operational.
$15k OSF/DCE server software (2 copies).
$130k = 1/2 FTE for 1 1/4 years ,split between ANL and ORNL.
($20k in FY '96, $110k in FY '97)