Product SiteDocumentation Site

Chapter 16. Authentication and Authorization

16.1. Authenticating servers
16.2. Host-based authentication
16.3. UNIX domain socket authentication
16.4. AF_NETLINK authentication of origin

16.1. Authenticating servers

When connecting to a server, a client has to make sure that it is actually talking to the server it expects. There are two different aspects, securing the network path, and making sure that the expected user runs the process on the target host. There are several ways to ensure that:
  • The server uses a TLS certificate which is valid according to the web browser public key infrastructure, and the client verifies the certificate and the host name.
  • The server uses a TLS certificate which is expectedby the client (perhaps it is stored in a configuration file read by the client). In this case, no host name checking is required.
  • On Linux, UNIX domain sockets (of the PF_UNIX protocol family, sometimes called PF_LOCAL) are restricted by file system permissions. If the server socket path is not world-writable, the server identity cannot be spoofed by local users.
  • Port numbers less than 1024 (trusted ports) can only be used by root, so if a UDP or TCP server is running on the local host and it uses a trusted port, its identity is assured. (Not all operating systems enforce the trusted ports concept, and the network might not be trusted, so it is only useful on the local system.)
TLS (Chapter 17, Transport Layer Security) is the recommended way for securing connections over untrusted networks.
If the server port number is 1024 is higher, a local user can impersonate the process by binding to this socket, perhaps after crashing the real server by exploiting a denial-of-service vulnerability.