How is security a function of Unix

archive

Professor Klaus Brunnstein from Hamburg is considered a vehement critic of the Unix operating system. His militant statement from earlier that he would lead a crusade against Unix, but he wants to understand it today in modified form: Unix is ​​not to be criticized in principle, but in detail. But these are crucial from a safety point of view. The interview conducted by COMPUTERWOCHE editor Jan-Bernd Meyer complements the statements made by Ingo Wieneke from AT&T in a counterpoint.

CW: Professor Brunnstein, is Unix an insecure operating system or not? Brunnstein: Unix itself does not have any mechanisms with which you can control how the access is. It also has a very dangerous file structure. It can be said to be a distributed networked system with independent directories. This distribution still gives it a certain degree of security because there is no summarizing criterion. The problem with Unix, however, is its root and system administrator concept.

CW: You mean that the possibilities of accessing the operating system involve the risks?

Brunnstein: There is an analysis about Unix security. The result was that Unix, because of its intrinsic properties, cannot be made so sure that it can be used for critical applications, i.e. sensitive applications in the military, finance, medical and industrial sectors. As early as 1976 it was written that it should not be used there. Nothing has changed in this situation to this day. Not even Posix, because Posix forgot to define security specifications in the operating system. Now you try to implement security from the outside as a shell.

CW: To ask again: There is no secure Unix version?

Brunnstein: There is an allegedly secure Unix system, Gould's Secure Unix. But this also has the usual weaknesses with tree access to the files.

CW: There is also the human element of uncertainty. . .

Brunnstein: You cannot make system security dependent on the reliability of a person. Basically you can say: if you have a system in which security is, so to speak, on the shell, then you have problems. That goes for IBM, for ACL. This applies to the security shells that are used today at Unix and also for PC protection software on MS-D0S. If you make a shell around the outside and you manage to get past the shell with system knowledge or whatever, then you are in possession of all properties including the possibility of impairing the integrity, the security, the availability of the system. This works just as well with MS-DOS as with Unix.

CW: So the shells are the troublemakers in Unix?

Brunnstein: Since Unix offers a lot of shells, efforts have been made to implement metashells. Shells with which, for example, electronic mail can be made available or with which programs can be specified. These shells are, of course, tools for breaking in. In order to get system access, the respective access rights have to be set quite high. That is why it is said that problems arise with the system administrators, not with the normal users.

CW: You mentioned the options for accessing the operating system: what do you think of remote maintenance options?

Brunnstein: If you want to maintain a software product remotely, as a software producer you naturally want to be able to transfer the software in the source code, induce the compilers and the system installation programs remotely and start the program. This mail function with debug was developed as a tool in Berkeley, because you can distribute new system versions in this way. They did not see that the system integrity was endangered.

CW: How do users react to something like that? Such mechanisms are very user-friendly for them ".

Brunnstein: The users at Xerox Park were relatively critical and said we didn't want that. The developers then assured them of that. Nonetheless, Berkeley built this debug feature into its product.

CW: What advantages do you see with the Unix operating system?

Brunnstein: Unix is ​​an excellent development system for software. So I would say: what you need would actually be two Unixes. A Unix that can be used to develop software. And a Unix with which you run programs developed on Unix in such a way that they can no longer be changed afterwards. That said, I'd take out all of that send-mail functionality with debugging features.

CW: Are there any developments for such a modified Unix system?

Brunnstein: We are developing such a Unix in Hamburg. We didn't use standard Unix, however. So neither Posix nor Unix System V, but Minix. This is a variant of Tannenbaum from Holland. We coreed that out and practically turned it into a production operating system. In this Unix, which will probably be ready by the end of the year, you can only install one program and it will shut down; you cannot make a virus attack on it because changing the program is not permitted. You can only uninstall and reinstall the program.

CW: Are there any fundamental properties that must be present in a secure Unix system?

Brunnstein: What is generally missing in Unix, which must be in all secure systems, is the so-called audit mechanism.

CW: What do you think of a message, the current Unix version from AT&T, the Unix. System V / MLS, Multilevel Security, Release 3.1 have now received the B1 classification according to the Orange Book classification. Can one now claim that there is a Unix version here that is safe?

Brunnstein: I suspect that AT&T basically says that we don't have send mail with debug functions. However, I wonder how you can prevent a user from installing the debug functions with the operating system. But I also have to say: B1 is undoubtedly a relevant step forward compared to a maximum of C2 today. In my opinion, the level where it actually gets interesting is B2.

CW: Well, security problems are not just a Unix specialty. . . Brunnstein: All virtual systems that convert physical access to disk storage and storage hierarchies and processes into logical requirements that are more secure than all physical access mechanisms, which undoubtedly also include Unix. VMS is of course more secure in this respect, but it cannot be compared in that the Unix system can often be made smaller than a Vax system. VM and MVS in the new versions are virtual in this sense. However, it has been shown that they are not efficient enough, too cumbersome. Fundamental difficulty: We have no reference mechanisms today, and they will probably only emerge in research. The BMFT is planning a research project to make a secure reference operating system in which both performance and security aspects are to be considered.

CW: Has there been any preliminary work to that?

Brunnstein: There is an internal group that was set up a month and a half ago. It's about the question of secure software. That means, methods of general specification of software and especially operating systems. Then you come to B3 and A1. These systems will not be 100% tamper-proof either. There will always be people who have very specific knowledge. They can then always put you on the back. But practically everyone can do that today. In the future it will only be the absolute system specialists. But the number of such specialists can certainly be reduced.

CW: What solution proposals do you have to establish an acceptable level of security in data centers?

Brunnstein: I would say virtual operating system before another. I would also suggest installing a Microvax as the front-end computer and a Unix computer behind it. That would certainly be an increase in security.

CW: You don't see a further development of Unix in terms of security?

Brunnstein: I don't know whether Unix can be further developed. But I can no longer imagine Unix above B2 at all.

CW: What do you think of OS / 2 as an alternative?

Brunnstein: Personally, I am not sure about the development of OS / 2 either, because the software gap is far from being closed. However, OS / 2 itself has better security mechanisms in the microchannel. There are also mechanisms in the operating system itself that offer more security. But that's not the end of the story. Further development will be necessary there. At the moment I see the 0S / 2 simply as an upgrade system from MS-DOS. The Unix world is one for technical applications and for development applications. The OS / 2 problem does not arise because Unix and OS / 2 are different areas of application.

CW: Do you have another tip for Unix users?

Brunnstein: I would advise every Unix user, if he is not just a developer, to fundamentally separate development and production. In a production system, he should slim down everything that can be slim down. Quasi on a core system on which only one program runs. For example, in the chemical industry, production descriptions for chemical processes. In addition, strict access control must be guaranteed. This is a bit of a mess with Unix today, because there are hardly any proper audit procedures. I see with great concern that relatively open Unix systems are used in some banking applications

become. They should be encapsulated. You should also try to avoid network communication - something like remote maintenance - from the outset. Better to create autonomous areas. If something happens then, of course, a diagnostic processor must be available to issue an appropriate warning. You should go to the site for maintenance tasks instead of using the admittedly convenient remote maintenance. The

Remotely servicing Unix is ​​a highly critical issue.

CW: So Unix is ​​not the operating system of the future?

Brunnstein: I'll tell you quite frankly: I have doubts whether Unix will spread like this. The incompatibilities of the Unix versions have still not been resolved. Posix is ​​still not enforced. The story with OSF is an all too vague possibility. The very long introduction period of Unix - you have to think about it, Unix is ​​over 15 years old - does not speak in favor of an operating system. It is quite possible that there will be some changes in the next five years, especially in the so-called distributed operating systems. Where there are individual processors and databases as servers. The operating system of the future is likely to be based much more on hardware components anyway. They get the information through cooperation. These concepts will be miles away from our operating systems today, including workstation operating systems.