Snet and the LSM API

A new security module, called snet (which is short for "security for network syscalls") was recently posted as an RFC on the linux-security-module mailing list. Its purpose is rather simple—much simpler than the two current mainline users of the LSM interface—intercept system calls for networking and call out to user space to determine if they are to be allowed. The idea is to be able to create Linux versions of the "personal firewall" that is popular on Windows machines. Reaction to snet was mixed, partially because of a disdain for that type of security tool, but also because it is implemented using LSM.

Snet, developed by Samir Bellabes, consists of a kernel piece which uses LSM to hook the "interesting" socket-related system calls (socket(), bind(), connect(), listen(), and accept()), as well as a user space library that can be used to accept or deny those calls. Communication between the kernel and user space is handled by a netlink socket using libnl. The decisions are then cached in the kernel to reduce the number of calls required to user space. That last part is important because personal firewalls typically pop up a request on the user's display asking them to decide whether to allow the system call. Timeouts can be established for the user-space calls, along with a default response if the timeout is reached.

This "user request" feature of personal firewalls is one thing that many find objectionable. As Paul Moore puts it: "my opinion is that it is a poor option for security and typically only results in training the user to click the 'allow' button when the pfwall [dialog] box pops up on his/her screen". Yet it is a "feature" of other operating systems and not completely unreasonable for Linux to support. From that perspective, snet seems like a reasonable starting point.

There are a few other problems, though, stemming from the decision to use the LSM API. Peter Dolding seems to think this capability should be added to netfilter, rather than built as a standalone solution. Others pointed out that netfilter is sufficiently low-level that any context about users or processes that are performing these operations is not available. That could change, but it would take a concerted effort to change the netfilter code, which doesn't seem likely near-term, if ever.

A larger problem comes from the inability to stack LSM modules. If a user is interested in the kinds of protection that snet can provide, they must forgo any other LSM-implemented security solution (i.e. SELinux, Smack, AppArmor, TOMOYO, etc.). A parallel discussion about LSM stacking is also occurring on linux-security-module, partially motivated by the needs of snet and other "smaller" security solutions. Those tools do not implement a full-scale security solution a la SELinux or Smack, but instead try to handle a smaller subset of the problem.

LSM stacking also came up at the LCA security panel, so it is certainly on the minds of Linux security developers. Casey Schaufler sums up the current state of affairs along with a look to a possible future:

It seems likely that someone will try to build an LSM-multiplexer before too long. In addition to snet, the TuxGuardian project appears to be reawakening after a period of quiet. It is similar to snet, and also uses LSM to trap network accesses. Other projects are also mentioned in the threads on linux-security-module. In the end, it is just too limiting to require that all security modules implement a full-scale security solution, and since LSM is the only accepted way to implement some of these hooks, some middle ground will likely be found.

In another related thread, Schaufler notes that a lot of what is being described for personal firewalls could be implemented using SELinux—at least as a starting point. One sticking point to that particular solution is the user interaction required. It is hard to see how an SELinux-derived solution could interact with the user for some decisions, but not others. It also is clearly outside of the scope of what SELinux is intended for.

While snet may implement "bad security" in some minds, the discussion about it, especially with regard to LSM stacking has been very valuable. It may turn out that there is no sane way to stack arbitrary security modules in a way that a) makes sense and b) doesn't drive all of the security developers insane. But there are some reasonable use cases for that capability so it would seem that an investigation of those possibilities is warranted. With luck we will soon see where it leads.