one host, he/she will then be able to log in on every host in these files without a password. This greatly broadens the possibilities for effective attack.

There are similar, but somewhat different issues with ssh and .shosts. The key-per-host scheme makes it possible to thwart these kinds of attacks, but ssh and sshd are rarely set up this securely, since the default implementation just leaves it up to the client to worry about spoofing.

12.5.6X11 security

Although many users are not aware of it, it is often possible to download the screen image of another user who is using the X-windows system. While this might occasionally be a useful opportunity to help remote users with a specific problem [337], in general it must be considered a grave security risk. It is equally possible to ‘bug’ the keyboard and listen to all the key-presses. The problem is an out-dated security mechanism which has long since been replaced, but which is still used by very many users. The problem is the xhost program. This is used to grant other hosts permission to draw on your X server – in other words, if you are remotely logged on to a host other than the one you are using as a display, you must grant the remote host access to write on your screen.

In the old X-windows system, prior to release 5, one had to grant access to a particular host. Once this was done, anyone on that host had access to your server, not just you. This was later replaced by the xauth magic-cookie mechanism which works on a user basis. Some users still insist on using xhost however, with a command like this:

xhost +

Any user writing this, opens their display to everyone in the world. The antidote, of course is the command xhost -. Users of the secure shell ssh, see section 12.6, can now have automatic X11 forwarding with authentication cookies. Everyone should therefore execute xhost - once and never use the xhost mechanism again.

12.6 VPNs: secure shell and FreeS/WAN

VPN stands for a Virtual Private Network. This is simply an encrypted tunnel (like an armored pipe) connecting two locations. It is a line of communication which is reinforced by encryption and authentication. Privacy is obtained through encryption and the line is virtual because it sits on top of regular TCP/IP communication. VPNs are sometimes uses to connect together branches of organizations that are located at geographically diverse locations; traffic can be kept ‘internal’, even though the packets travel over public media. Of course, an armored pipe is no stronger than its weakest end-point.

Secure shell software can be used to build VPNs for many services. The secure shell [332] is a secure replacement for the rsh commands. It protects against IP spoofing where a remote host pretends to be a trusted host by faking IP datagrams; DNS spoofing where an attacker forges name entries in the name-service; the interception of passwords in network packets and several other kinds of attack.

FreeS/WAN is another project [247] started for GNU/Linux systems which will provide encrypted tunnels. See also the Virtual Private Network Consortium [74].

12.7 Role-based security and capabilities

In a dynamic, interactive situation we could generalize the notion of access to allow users different permissions depending on what they are doing. This can be done in different ways:

•Define roles for users (e.g. by membership in privileged groups with access to special systems, like man in Unix).

•By asking a service to carry out an operation, whose abilities have the appropriate privileges for the task (e.g. WWW, telnet, Java).

•By setting some attribute which determines the allowed permissions for a given task (e.g Unix setuid programs).

•Use of abstract ownership (e.g. polymorphic methods in object-oriented languages).

Unix setuid programs are an example where the activities of a program can be changed (by the superuser) so as to grant a specific program the right to operate with a different user-identity and thus privileges (without authentication). The setgid is a corresponding mechanism for setting the group ownership of a process. Note that setuid programs often give more privilege than is necessary and such programs have been a major cause of security problems on Unix platforms.

POSIX ‘Capabilities’ have recently been implemented in the Linux kernel [57]. These ‘Capabilities’ are an additional form of privilege control to enable more specific control over what privileged processes can do by giving them a direct line to the kernel. Rather than making a program ‘setuid root’, one could give a program privilege to perform a specific task and nothing more. Other examples are Rule Set Based Access Control (RSBAC), and LIDS (Secure Linux Project) which implement Mandatory Access Control in the kernel for all kinds of operations on files and processes. This presents some administrative difficulties for software, since there is no longer any user with complete privilege.

12.8 WWW security

The concept of World Wide Web (WWW) security sounds like a contradiction in terms. The WWW is designed to publish information to the masses. Security has to do with restricting access. What has the WWW got to do with security?

Web security has to do with:

•Protecting the published data from corruption.

•Granting access only to those files we wish to publish.

•Preventing users from tricking the WWW server into executing unauthorized commands on the server host.

•Protecting against a protocol that opens the system to all manner of attacks through abuses of the protocol.

Although there have been many security problems with the feature over-laden Internet Information Server for Windows [300], there is nothing principally insecure about the WWW service. Any file-server can, in principle, compromise the security of a host by making information about that host available to others. If a server provides access to unauthorized files, this will clearly be the case. All we need to do is to ensure that proper access controls are maintained.

The Free Apache WWW server (see section 9.6) has all of the features one requires to operate a secure web service. It can be run without special privilege, and it has quite sophisticated mechanisms for restricting access to data. It is nevertheless possible to configure the server in an insecure fashion, so one needs to be cautious. There are three distinct categories for web use:

•External web service for organization.

•Internal web service for organization.

•Private users’ web pages.

The last of these is arguably the greatest potential security risk for the Web: we usually trust the files and programs which we write ourselves in the name of our organization, but we have no reason to trust the integrity of private or guest users. There are two areas where a security breach can occur:

•File ownership and access rights.

•CGI-scripts.

CGI-scripts can be used to execute commands on the server-host with the userprivileges of the WWW user. Although the WWW user is introduced precisely to isolate the powers of the WWW service, we can still do quite a bit of damage – not to the host directly, but to other users and to the web server access controls. It is an inevitable consequence of running a public service with a private ID that any file which gets written by a CGI-script can also be overwritten by another CGI-script, regardless of which user is responsible for that script. Thus users could wage war on one another with CGI-scripts such as guest-books, corrupting or even deleting one another’s data freely. This is a fundamental weakness in the WWW service: if we allow the existence of arbitrary CGI-scripts on the system, then we can carry out arbitrary operations with the privileges of the WWW user. Users can:

•Send anonymous, untraceable mail which appears to come from the WWW user at the organization hosting the CGI program.

•Circumvent .htaccess access controls to certain files on most types of operating system, by executing the command /bin/cat filename as part of a CGI-script.

The first principle of server security is thus:

Principle 64 (Service corruption). If a server runs with the privileges of a non-privileged user, then none of the data or configuration files of the system should be owned by, or be writable by the www user, otherwise it is often trivial to alter the contents of the data using the service.

Example 18. The WWW server usually runs under a user ID of www. If any of the data files or configuration files are owned by this user, it is trivial to write a CGI-script that gives complete control of the service to any outside user.

If we violate this principle, any local user can overwrite and corrupt web pages simply by writing a CGI-script. Of course, the WWW server does not have any special privileges. It is just an ordinary, non-privileged user who has to obey normal file permissions, nevertheless this is not enough to prevent a few accidents. This brings us to the fundamental flaw in WWW security.

Any files which are to be served by a WWW server have to be readable by the WWW user. All CGI-scripts run with the rights of the WWW user. It therefore follows that any CGI-script can read any file which is capable of being served by the daemon. To put it bluntly: Any user can write a CGI-script to circumvent .htaccess security barriers. The solution to this problem is to either disallow CGI-scripts, or to move sensitive (non-public) documents to a separate host, which regular users do not have access to.

CGI-scripts which send mail are a conundrum. If a user decides to write a CGIscript which sends E-mail, it executes the mail program with the user identity of the WWW user. The identity of the true sender is irrelevant, since the actual sender is the WWW server. This could be an unfortunate situation for an organization. If private users can send E-mail anonymously, but which can be traced back to the WWW server of our organization, we clearly stand in the firing line for all kinds of trouble. A user could harass anyone with impunity, and only the organization would be responsible.

12.9 IPSec – secure IP

Many problems in network communication would be easily solved if there were transport layer encryption of Internet traffic. Spoofing would be impossible, because attackers would have access to cryptographic checksums of the packets (spoofing could be easily detected). Similarly sniffing the net for passwords, leaked by old protocols, would be impossible, since no plaintext data would be sent.

IPSec is a security system developed for use with IPv6, but it has also been implemented for IPv4 (RFC1636). It offers encryption at the IP level (below the TCP/UDP layer). This means that common TCP attacks, such as sequence guessing or spoofing attacks, cannot occur since attackers could never see the contents of travelling packets.

IPSec allows hosts to set security policies on routed packets. It includes access control lists for encryption, integrity checks and point-to-point private tunnels. This all sounds like the perfect solution to the problem, however IPSec is not

without problems: it is not fully implemented by network hardware and software today. This could take some time.

IPSec supports both session encryption and strong authentication, based on either public or secret keys. It consists approximately of two protocols:

•Authentication Header (AH): this describes the initial negotiation of identity and encryption methods.

•Encapsulation Security Payload (ESP): this describes the encryption schemes and also relates to the strong authentication of data.

These provide the following services:

•Access control

•Connectionless integrity

•Data origin authentication

•Replay protection

•Privacy (encryption).

12.9.1Security Associations (SA)

IPSec maintains a security context known as a Security Association (SA), which is a policy decision that times out after a specified lifetime. A Security Association is uniquely defined by three parameters:

•Security Parameters Index: This is a context identifier.

•IP destination address: A unicast address that is to be the endpoint for the SA (but not necessarily the endpoint of a packet/datagram).

•Security Protocol Identifier: Indicates whether an AH or ESP security method is to be used.

Decisions based on these parameters are collected into a Security Policy Database (SPD), where they are examined for each packet or datagram that is forwarded by a router, firewall or host. IPSec is designed to offer great flexibility to administrators; however, with such power comes the possibility of great error as we shall see in section 12.10. IPSec offers the possibility to distinguish between a variety of security options for traffic routed along different paths, using selectors.

12.9.2Selectors

An IPSec Security Association policy is built up from selectors, or matching parameter sets that are compared with high-level packet header fields. Selectors are used to filter outgoing traffic from a router or firewall. Each packet is processed as follows:

1.Compare header field values with the values stored in the policy database and select zero or more Security Associations determining the packet’s outcome.