WINDOWS VS. LINUX DESIGN

January 10, 2020January 10, 2020 Krishna DESIGN, GRAPHICAL DESKTOP INTERFACE, Linux, RPC MODEL, Windows, WINDOWS VS. LINUX DESIGN

It is possible that email and browser-based viruses, Trojans and worms are the source of the myth that Windows is attacked more often than Linux. Clearly there are more desktop installations of Windows than Linux. It is certainly possible, if not probable, that Windows desktop software is attacked more often because Windows dominates the desktop. But this leaves an important question unanswered.

Do the attacks so often succeed on Windows because the attacks are so numerous, or because there are inherent design flaws and poor design decisions in Windows? Many, if not most of the viruses, Trojans, worms and other malware that infect Windows machines do so through vulnerabilities in Microsoft Outlook and Internet Explorer. To put the question another way, given the same type of desktop software on Linux (the most often used web browsers, email, word processors, etc.), Are there as many security vulnerabilities on Linux as Windows?

WINDOWS DESIGN

Viruses, Trojans and other malware make it onto Windows desktops for a number of reasons familiar to Windows and foreign to Linux:

Windows has only recently evolved from a single-user design to a multi-user model
Windows is monolithic, not modular, by design
Windows depends too heavily on an RPC model
Windows focuses on its familiar graphical desktop interface.

Windows has only recently evolved from a single-user design to a multi-user model Critics of Linux are fond of saying that Linux is old technology. Ironically, one of the biggest problems with Windows is that it hasn‘t been able to escape its ―old‖ legacy single-user design. Windows has long been hampered by its origin as a single-user system. Windows was originally designed to allow both users and applications free access to the entire system, which means anyone could tamper with a critical system program or file. It also means viruses, Trojans and other malware could tamper with any critical system program or file, because Windows did not isolate users or applications from these sensitive areas of the operating system.

Windows XP was the first version of Windows to reflect a serious effort to isolate users from the system, so that users each have their own private files and limited system privileges. This caused many legacy Windows applications to fail, because they were used to being able to access and modify programs and files that only an administrator should be able to access. That‘s why Windows XP includes a compatibility mode – a mode that allows programs to operate as if they were running in the original insecure single-user design. This is also why each new version of Windows threatens to break applications that ran on previous versions. As Microsoft is forced to hack Windows into behaving more like a multi-user system, the new restrictions break applications that are used to working without those restraints.

WINDOWS IS MONOLITHIC BY DESIGN, NOT MODULAR

A monolithic system is one where most features are integrated into a single unit. The antithesis of a monolithic system is one where features are separated out into distinct layers, each layer having limited access to the other layers.

While some of the shortcomings of Windows are due to its ties to its original single-user design, other shortcomings are the direct result of deliberate design decisions, such as its monolithic design (integrating too many features into the core of the operating system). Microsoft made the Netscape browser irrelevant by integrating Internet Explorer so tightly into its operating system that it is almost impossible not to use IE. Like it or not, you invoke Internet Explorer when you use the Windows help system, Outlook, and many other Microsoft and third-party applications. Granted, it is in the best business interest of Microsoft to make it difficult to use anything but Internet Explorer. Microsoft successfully makes competing products irrelevant by integrating more and more of the services they provide into its operating system. But this approach creates a monster of inextricably interdependent services (which is, by definition, a monolithic system). Interdependencies like these have two unfortunate cascading side effects. First, in a monolithic system, every flaw in a piece of that system is exposed through all of the services and applications that depend on that piece of the system. When Microsoft integrated Internet Explorer into the operating system, Microsoft created a system where any flaw in Internet Explorer could expose

your Windows desktop to risks that go far beyond what you do with your browser. A single flaw in Internet Explorer is therefore exposed in countless other applications, many of which may use Internet Explorer in a way that is not obvious to the user, giving the user a false sense of security. This architectural model has far deeper implications that most people may find difficult to grasp, one being that a monolithic system tends to make security vulnerabilities more critical than they need to be.

Perhaps an admittedly oversimplified visual analogy may help. Think of an ideally designed operating system as being comprised of three spheres, one in the center, another larger sphere that envelops the first, and a third sphere that envelope the inner two. The end-user only sees the outermost sphere. This is the layer where you run applications, like word processors. The word processors make use of commonly needed features provided by the second sphere, such as the ability to render graphical images or format text. This second sphere (usually referred to as userland by technical geeks) cannot access vulnerable parts of the system directly. It must
request permission from the innermost sphere in order to do its work. The innermost sphere has the most important job, and therefore has the most direct access to all the vulnerable parts of your system. It controls your computer‘s disks, memory, and everything else. This sphere is called the kernel., and is the heart of the operating system. In the above architecture, a flaw in the graphics rendering routines cannot do global damage to your computer because the rendering functions do not have direct access to the most vulnerable system areas. So even if you can convince a user to load an image with an embedded virus into the word processor, the virus cannot damage anything except the user‘s own files, because the graphical rendering feature lies outside the innermost sphere, and does not have permission to access any of the critical system areas.

The problem with Windows is that it does not follow sensible design practices in separating out its features into the appropriate layers represented by the spheres described above. Windows puts far too many features into the core, central sphere, where the most damage can be done. For example, if one integrates the graphics rendering features into the innermost sphere (the kernel), it gives the graphical rendering feature the ability to damage the entire system. Thus, when someone finds a flaw in a graphics-rendering scheme, the overly integrated architecture of Windows makes it easy to exploit that flaw to take complete control of the system, or destroy the entire system.

Finally, a monolithic system is unstable by nature. When you design a system that has too many interdependencies, you introduce numerous risks when you change one piece of the system. One change may (and usually does) have a cascading effect on all of the services and applications that depend on that piece of the system. This is why Windows users cringe at the thought of applying patches and updates. Updates that fix one part of Windows often break other existing services and applications. Case and point: The Windows XP service pack 2 already has a growing history of causing existing third-party applications to fail. This is the natural consequence of a monolithic system – any changes to one part of the machine affect the whole machine, and all of the applications that depend on the machine.

WINDOWS DEPENDS TOO HEAVILY ON THE RPC MODEL

RPC stands for Remote Procedure Call. Simply put, an RPC is what happens when one program sends a message over a network to tell another program to do something. For example, one program can use an RPC to tell another program to calculate the average cost of tea in China and return the answer. The reason it‘s called a remote procedure call is because it doesn‘t matter if the other program is running on the same machine, another machine in the next cube, or somewhere on the Internet.

RPCs are potential security risks because they are designed to let other computers somewhere on a network to tell your computer what to do. Whenever someone discovers a flaw in an RPC-enabled program, there is the potential for someone with a network-connected computer to exploit the flaw in order to tell your computer what to do. Unfortunately, Windows users cannot disable RPC because Windows depends upon it, even if your computer is not connected to a network. Many Windows services are simply designed that way. In some cases, you can block an RPC port at your firewall, but Windows often depends so heavily on RPC mechanisms for basic functions that this is not always possible. Ironically, some of the most serious vulnerabilities in Windows Server 2003 (see table in section below) are due to flaws in the Windows RPC functions themselves, rather than the applications that use them. The most common way to exploit an RPC-related vulnerability is to attack the service that uses RPC, not RPC itself.

It is important to note that RPCs are not always necessary, which makes it all the more mysterious as to why Microsoft indiscriminately relies on them. Assume for a moment that you create a web site using two servers. One server is a dedicated database server, and the other server is a dedicated web server. In this case, it is necessary for the database server to use RPCs, because the web server is on a separate machine and must be able to access the database server over the network connection. (Even in this case, one should configure the database server to listen only to the web server, and no other machine.) If you run both the database server and web server on the same machine, however, it is not only unnecessary for the database server to use RPCs, it is unwise to do so. The web server should be able to access the database server directly, because the two are running on the same machine. There is no technical or logical reason to expose the database server to the network, because it presents an unnecessary security risk.

We raise the issue of database servers because the Slammer worm, one of the most profoundly dangerous worms ever to hit the Internet, exploited one of the most inappropriate uses of RPC-like network communications ever implemented by Microsoft. Slammer infected so many systems so quickly that it practically brought the Internet to a standstill.

The Slammer worm caused havoc by exploiting two flaws in Microsoft SQL Server, a client/server SQL database server. One flaw was a most improbable feature of Microsoft SQL Server – one that allows you to run more than one instance of the database server at a time on a single machine. Here is why it is improbable. If you‘re not familiar with database servers, picture it this way. Under normal conditions, it makes no sense to run multiple instances of a database server on a single machine, because one instance is all that is needed, even if many different applications use it. One would be as likely to want to run two copies of Windows XP on a single machine at the same time as want to run multiple database servers on a single machine at the same time. One rarely runs multiple instances of a database server on purpose, except in high-end applications or for testing and development.

The easy way to allow multiple instances of SQL Server to run simultaneously without interfering with one another is to create an RPC mechanism that sorts out requests for data, so that a fax application queries its own copy of SQL Server, and a time-billing application queries yet another copy of SQL Server. To complicate matters, Microsoft development tools encourage the same monolithic approach Microsoft uses, so a broad range of applications – time-billing software, fax software, project management – almost 200 applications, many of them desktop applications, use the unnecessarily vulnerable SQL Server engine. As a result, hundreds of thousands, if not millions, of people use desktop applications that depend on the SQL Server engine with multiple network services enabled, many of which are exposed to the Internet. One could hardly concoct a better recipe for disaster.

As a result, Slammer found countless machines to attack because these features are enabled by default on every SQL Server engine. While SQL Server is not yet integrated into Windows, its ubiquity across applications from fax software to time billing software made it effectively a part of a larger monolithic system, thus opening the way to an attack path that is symptomatic of a monolithic system. Unfortunately, SQL Server is likely to be tightly integrated into the upcoming new Windows File System WinFS originally slated for Longhorn. If anyone thinks integrating SQL Server into the operating system is a good idea, they should consider what happened with the Slammer worm.

WINDOWS FOCUSES ON ITS FAMILIAR GRAPHICAL DESKTOP INTERFACE

Microsoft considers its familiar Windows interface as the number one benefit for using Windows Server 2003. To quote from the Microsoft web site, ―With its familiar Windows interface, Windows Server 2003 is easy to use. New streamlined wizards simplify the setup of specific server roles and routine server management tasks…‖

By advocating this type of usage, Microsoft invites administrators to work with Windows Server 2003 at the server itself, logged in with Administrator privileges. This makes the Windows administrator most vulnerable to security flaws, because using vulnerable programs such as Internet Explorer expose the server to security risks.

LINUX DESIGN

According to the summer 2004 Evans Data Linux Developers Survey, 93% of Linux developers have experienced two or fewer incidents where a Linux machine was compromised. Eighty-seven percent had experienced only one such incident and 78% have never had a cracker break into a Linux machine. In the few cases where intruders succeeded, the primary cause was inadequately configured security settings.

More relevant to this discussion, however, is the fact that 92% of those surveyed have never experienced a virus, Trojan, or other malware infection on Linux. Viruses, Trojans and other malware rarely, if ever, manage to infect Linux systems, in part because:

Linux is based on a long history of well fleshed-out multi-user design
Linux is mostly modular by design
Linux does not depend upon RPC to function, and services are usually configured not to use RPC by default
Linux servers are ideal for headless non-local administration

Keep in mind when reading the summaries below that there are variations in the default configurations of the different distributions of Linux, so what may be true of Red Hat Linux may not be true of Debian and there may be even more differences in SuSE. For the most part, all the major Linux distributions tend to follow sane guidelines in the default configurations.

LINUX IS MODULAR BY DESIGN, NOT MONOLITHIC

Linux is for the most part a modularly designed operating system, from the kernel (the core brains of Linux) to the applications. Almost nothing in Linux is inextricably intertwined with anything else. There is no single browser engine used by help systems or email programs. Indeed, it is easy to configure most email programs to use a built-in browser engine to render HTML messages, or launch any browser you wish to view HTML documents or jump to links included in an email message. Therefore a flaw in one browser engine does not necessarily present a danger to any other application on the system, because few if any other applications besides the browser itself must depend on a single browser engine.

Not everything in Linux is modular. The two most popular graphical desktops, KDE and GNOME, are somewhat monolithic by design; at least enough so that an update to one part of GNOME or KDE can potentially break other parts of GNOME or KDE. Neither GNOME nor KDE are so monolithic, however, as to require you to use GNOME or KDE-specific applications. You can run GNOME applications or any other applications under KDE, and you can run KDE or any other applications under GNOME. The Linux kernel supports modular drivers, but it is essentially a monolithic kernel where services in the kernel are interdependent. Any adverse impact of this monolithic approach is minimized by the fact that the Linux kernel is designed to be as minimal a part of the system as possible. Linux follows the following philosophy almost to a point of fanaticism: ―Whenever a task can be done outside the kernel, it must be done outside the kernel.This means that almost every useful feature in Linux (―useful‖ as perceived by an end user) is a feature that does not have access to the vulnerable parts of a Linux system.

LINUX IS NOT CONSTRAINED BY AN RPC MODEL

As stated above in the section on Windows, RPC stands for Remote Procedure Call. Simply put, an RPC allows one program to tell another program to do something, even if that other program resides on another computer. For example, one program can use an RPC to tell another program to calculate the average cost of tea in China and return the answer. The reason it‘s called a remote procedure call is because it doesn‘t matter if the other program is running on the same machine,
another machine in the next cube, or somewhere on the Internet.

Most Linux distributions install programs with network access turned off by default. For example, the MySQL SQL database server is usually installed such that it does not listen to the network for instructions. If you build a web site using Apache and MySQL on the same server machine, then Apache will interact with MySQL without MySQL having to listen to the network. Contrast this to SQL Server, which listens to the network whether or not it is necessary to do so. If you want MySQL to listen to the network, you must turn on that feature manually, and then explicitly define the users and machines allowed to access MySQL. Even when Linux applications use the network by default, they are most often configured to respond only to the local machine and ignore any requests from other machines on the network.

Unlike Windows Server 2003, you can disable virtually all network-related RPC services on a Linux machine and still have a perfectly functional desktop.

LINUX SERVERS ARE IDEAL FOR HEADLESS NON-LOCAL ADMINISTRATION

A Linux server can be installed, and often should be installed as a ―headless‖ system (no monitor is connected) and administered remotely. This is often the ideal type of installation for servers because a remotely administered server is not exposed to the same risks as a locally administered server.For example, you can log into your desktop computer as a normal user with restricted privileges and administer the Linux server through a browser-based administration interface. Even the most critical browser-based security vulnerability affects only your local user-level account on the desktop, leaving the server untouched by the security hole. This may be one of the most important differentiating factors between Linux and Windows, because it virtually negates most of the critical security vulnerabilities that are common to both Linux and Windows systems, such as the vulnerabilities of the Mozilla browser vs. the Internet Explorer browser.