Trust is one of the most, if not the most, important concepts in SATAN. The issues and implications of trust are a bit more subtle and far-reaching than what we've covered before; in the context of this documentation we use the word trust whenever there is a situation when a server (note that any host that allows any remote access can be called a server) can have a local resource either used or compromised by a client with or without the proper authorization. In addition, trust is transitive; e.g. if host B trusts host A, and an intruder can compromise host A, then the intruder can also compromise host B.

There are many ways that a host can trust: .rhosts and hosts.equiv files that allow access without password verification are the most common, but other examples are window servers that allow remote systems to use and abuse privileges; export files that control access via NFS, etc. However (and this is the most controversial statement about trust), we also say that if a host has had login accesses from another host, that the former host trusts the latter. The reason for this is that unless extra authentication is being used, if a user logs in from a compromised remote host then the attacker can steal the password and data streams from the legitimate user and can almost compromise the host in question.

Although the concept of how host trust works is well understood by most system administrators, the dangers of trust, and the practical problem it represents, irrespective of trickier attacks such as hostname impersonation and IP spoofing, is one of the least understood problems we know of on the Internet. This goes far beyond the obvious hosts.equiv and rhosts files; NFS, NIS, windowing systems -- indeed, much of the useful services in UNIX are based on the concept that well known (to an administrator or user) sites are trusted in some way. What is not understood is how networking so tightly binds security between what are normally considered disjoint hosts.

Any form of trust can be spoofed, fooled, or subverted, especially when the authority that gets queried to check the credentials of the client is either outside of the server's administrative domain, when the trust mechanism is based on something that has a weak form of authentication, or if the security of the other system involved is outside of the direct control of the system administrator. One or more of these are usually true.

Back to the Introductory TOC/Index