Security Distribution for Linux Clusters

We used the LSM security hooks in the DSM to add our security labels to the IP messages. We now demonstrate how we achieved this by presenting an example of an application that sends a packet over the network by writing to a socket. The application uses some of the library calls. At one point, a system call is generated that passes the message to the Linux kernel. The entry point to the kernel socket implementation is the function sys_socketcall(), located in net/socket.c. In the chain of calls, the sock_sendmsg() function (Listing 1) in net/socket.c is executed.

sock_sendmsg
(struck socket *sock, struct msghdr *msg, int size)
{
  int err;
  struct scm_cookie scm;

  err =
    security_ops->socket_ops->sendmsg(sock,
                                      msg, size);
  if(err)
    return(err);
  ...

}

One of the first actions in the function is to execute the security hook (security_ops->socket_ops->sendmsg(...)). This hook ends up in the DSM socket hook that modifies the IP packet, as shown in Listing 2.

int dsi_socket_sendmsg(struct socket *sock,
                       struct msghdr *msg, int size)
{
...

inode_security_t *isec;
struck sock sk;
struct ip_options *opt =  NULL;
int optlen = NSID_BASE_LEN + NSID_SSID_LEN +
             NSID_NODEID_LEN; //8 +_6 + 6
unsigned char optptr[optlen];

  ...

  sk = sock->sk;
  opt = sk->protinfo.af_inet.opt;
  dsi_options_fill (isec, optptr, optlen);
  dsi_ip_options_get(&opt, optptr, optlen);
  opt = xchg(&sk->protinfo.af_inet.opt, opt);

...
}

The function dsi_options_fill sets up the security information to the buffer as specified in the previous paragraph. Later, in subsequent functions, this security information is attached to the IP message as options. The SID is derived from the socket security ID, and the NID is global for the whole node—there is no need to pass it as a parameter to the function.

After this action, the modified packet with the security information added is forwarded for normal processing in the kernel and finally is sent over the network. At the receiving side, the incoming messages are stored in the sk_buff structures and preprocessed in a series of functions and hooks. One of these functions is ip_options_compile (Listing 3) in /net/ipv4/ip_options.c, where the options are processed.

int
ip_options_compile (struct ip_options *opt,
                    struct sk_buff *skb)
{
unsigned char *pp_ptr;
unsigned char *optptr;

  ...

  case IPOPT_CIPSO:

    if(security_ops->ip_ops->decode_options(skb,
                                    optptr, &pp_ptr)
      goto error;
      break;
  ...
}

For the CIPSO case, the security hook decode_options is called. This hook is replaced by the DSM dsi_decode_options hook, where the security parameters (SID, NID) from the incoming packet are read and stored in the security structure attached to this sk_buff. The sk_buff buffers, populated with the security information, are attached to the receiving socket queue, where they are waiting to be read by the receiving application. In order to read them, the application issues the system call sys_socketcall (), as it did for the sending packet. The call once again goes through the DSM security hook, where the receiving socket security ID is validated against the sk_buff security of the incoming packet. If the socket is not allowed to receive the packets with a given security ID, then those packets are dropped. Listing 4 shows the kernel function in include/net/sock.h.

int
sock_queue_rcv_skb (struct sock *sk,
                    struct sk_buff *skb)
{
int err=0;

  ...

  err=security_ops->socket_ops->sock_rcv_skb (sk,
                                              skb);

  if(err)
    return (err);
  ...
}

As we can see, the security hook sock_rcv_skb is called. This hook then is replaced by the DSM function dsi_sock_rcv_skb when the DSM is loaded. In this function, the security validation is performed. From the example code we can see work needs to be done to manipulate the security labels.