Comparing with other security models --------------------------------------------------------- I. Linux capability Part of sysmask bears apparent resemblance with Linux capability implementation, in particular with the projected user capabilities. However, there are two major differences. Firstly, the implementation of sysmask is much more centralized, with the number of checkpoints reduced to as small as possible. The objective of this choice is to reduce the possibility of bugs in the security scheme itself. The kernel is in constant movement, and with each modification, there is a risk of new bug for every checkpoint. Therefore the fewer checkpoints the better. The design also means simplification of configuration, which implies less human error by sysadmins, a very important security factor. In the same time, refined access filtration is not sacrificed, including features like selective file access according to the type of the operation (distinction among symlink, link, read, write, rename, stat etc). Secondly, compared to the fact that there exist several methods to lift capability restrictions applied to a process, sysmask provides only one: the daemon smkd. A centralized controler that significantly reduces the risk of human errors resulting from bad configuration. It also makes automated auditing easier and more reliable. --------------------------------------------------------- II. SELinux With respect to the possibility of defining individual access control policy for each process, there are recognizable similarities between sysmask and SELinux. While several shortcomings in the design of SELinux are corrected in sysmask: 1. SELinux makes no attempt to protect against kernel vulnerabilities. There is also a lack of efficient resource consumption control. 2. There are much less checkpoints and less code complicatedness in sysmask than in SELinux, hence less probability of bugs in the package itself. 3. The configuration of SELinux is too rigid, on a very technical syntax. All that lead to more probability in human configuration errors. 4. SELinux often requires program recompilation to get a good level of protection. Moreover, sysmask introduces an important new feature: the possibility of trigger configurable security reactions by various actions of the process. This feature significantly increases the flexibility of the system, and opens up many new schemes of implementation. The reaction of sysmask becomes interactive, compared with that of other models that are basically static. There is also the example of X Windows that illustrates well the difference between SELinux and sysmask. SELinux offers a sophisticated inter-client security mechanism but does not address the risk resulting from a vulnerability in the X server, while sysmask does exactly the contrary. Of course, if you really need both you can install both: sysmask can coexist with other security packages including SELinux. ---------------------------------------------------------- III. Systrace Systrace is a security package primarily designed for BSD systems, and partially ported to Linux. Its action on individual processes is very similar to that of Sysmask (without smkd), but for the triggering possibility. And the biggest advantage of Sysmask here is the existence of a central controler (that is, smkd) who takes care of interactive security reactions. It is this controler that makes it possible to configure an entire system as tightly as possible. As an example, sshd is an exposed process that must launch user login shells when authentications are accepted. So if sshd is to be confined so that it cannot escape the restrictions by launching a child, then all user login shell privileged should be given to sshd itself, which means that no serious restriction can be made. If sshd can decide by itself to remove some of the restrictions, then an exploit too has the possibility to escape, say, by simulating a successful login. While if only smkd can decide when and how to remove restrictions, an exploit has no possibility to escape without giving the right authentication action. ---------------------------------------------------------- Linux prepares a structure of "Linux Security Module" (LSM), that supposedly should be the common frame of all security implementations for the kernel. Sysmask didn't adopt it, mainly because it does not fit several main design principles of sysmask. As a result, sysmask may coexist with any other security package within the frame of LSM. Of course, whether such a coexistence makes sense in practice is another question. --------------------------------------------------------- Another big difference of sysmask with other security packages is that most other packages require the cooperative actions by the protected softwares. On the other hand, sysmask can work in a 100% coercive way, asking no cooperation from the protected softwares.