The Trusted Extensions software supports network communication by using Berkeley sockets and the TLI over single-level ports and multilevel ports. The AF_UNIX family of system calls establishes interprocess connections in the same labeled zone by means of a special file that is specified by using a fully resolved path name. The AF_INET family of system calls establishes interprocess connections across the network by using IP addresses and port numbers.
In the AF_UNIX family of interfaces, only one server bind can be established to a single special file, which is a UNIX® domain socket. The AF_UNIX family does not support multilevel ports.
Like UNIX domain sockets, doors and named pipes use special files for rendezvous purposes.
The default policy for all Trusted Extensions IPC mechanisms is that they are all constrained to work within a single labeled zone. The following are exceptions to this policy:
The global zone administrator can make a named pipe (FIFO) available to a zone whose label dominates the owning zone. The administrator does this by loopback-mounting the directory that contains the FIFO.
A process that runs in the higher-level zone is permitted to open the FIFO in read-only mode. A process is not permitted to use the FIFO to write down.
A labeled zone can access global zone door servers if the global zone rendezvous file is loopback-mounted into the labeled zone.
The Trusted Extensions software depends on the door policy to support the labeld and nscd doors-based services. The default zonecfg template specifies that the /var/tsol/doors directory in the global zone is loopback-mounted into each labeled zone.
In the AF_INET family, the process can establish a single-label connection or a multilabel connection to privileged or unprivileged port numbers. To connect to privileged port numbers, the net_priv_addr privilege is required. If a multilevel port connection is sought, the net_bindmlp privilege is also required.
The server process needs the net_bindmlp privilege in its effective set for a multilevel port connection. If a single-level port connection is made instead, the server process needs mandatory read-equal access to the socket, and the client process needs mandatory write-equal access. Both processes need mandatory and discretionary access to the file. If access to the file is denied, any process that is denied access needs the appropriate file privilege in its effective set to gain access.
The following code example shows how a multilevel server can obtain the labels of its connected clients. The standard C library function getpeerucred() obtains a connected socket or a STREAM peer's credentials. In the context of Trusted Extensions, when the listening socket of a multilevel port server accepts a connection request, the first argument is typically a client socket file descriptor. The Trusted Extensions application uses the getpeerucred() function in exactly the same way a normal application program does. The Trusted Extensions addition is ucred_getlabel(), which returns a label. For more information, see the ucred_get(3C) man page.
/*
* This example shows how a multilevel server can
* get the label of its connected clients.
*/
void
remote_client_label(int svr_fd)
{
ucred_t *uc = NULL;
m_label_t *sl;
struct sockaddr_in6 remote_addr;
bzero((void *)&remote_addr, sizeof (struct sockaddr_in6));
while (1) {
int clnt_fd;
clnt_fd = accept(svr_fd, (struct sockaddr *)&remote_addr,
&sizeof (struct sockaddr_in6));
/*
* Get client attributes from the socket
*/
if (getpeerucred(clnt_fd, &uc) == -1) {
return;
}
/*
* Extract individual fields from the ucred structure
*/
sl = ucred_getlabel(uc);
/*
* Security label usage here
* .....
*/
ucred_free(uc);
close(clnt_fd);
}
}