How secure is sysmask? ----------------------------------------------------- No, sysmask does not eliminate vulnerabilities. It is there to make vulnerabilities much less harmful than before, to the point that you can just live with them without being hurt. Especially for potential future vulnerabilities, so you can forget about security alerts, anti-viruses and unterminable upgrades. The objective is to achieve theoretical (that is, absolute) security against certain well-identified risks: exploiting bugs in a running system to gain unauthorized access rights to the system. Examples include infiltration through a vulnerable network daemon, local user root privilege elevation via a kernel vulnerability, or installation of a virus in user account through a vulnerable browser or mail agent. While this goal is not yet reached, the actual version can successfully reduce the security-sensitive codes of a system to a very small portion of the kernel. So small that hopefully one day a proof checker can be run on it and prove its solidity. In any case, between the theoretical unbreakability of a system and an effective exploit to break it, there is a huge gap. What can be proved now, is that a system with properly configured sysmask can be broken only if there is an exploitable vulnerability within the following portions of the code: 1. Codes behind a list of frequently used system calls. The actual list depends on the configuration but can be explicitly established. 2. The basic codes of the kernel: memory management, scheduler, exception handler. 3. A short list of device drivers, depending on the configuration. 4. The sysmask itself: kernel patch, daemon code and configuration. In practice, historically extremely few vulnerabilities have ever been discovered within the first three items. As for sysmask itself, it is designed to be very small and simple, its sensitive parts (the daemon) being independent on outside libraries including libc. Once fully tested by its deployment, the chance for bugs to resist in this package is slim. Note that this list of security-sensitive parts does not include any user space programs, daemon or not, nor any dynamic library. In fact, in order to break a sysmask-protected system, a network exploit must simultaneously break three barriers: A. Break a daemon (or browser) to make it execute arbitrary codes. B. Use the above codes to exploit a vulnerability within the above security-sensitive parts, to break into the kernel. C. Use the kernel breaking to get rid of the sysmask protection for the compromised process, or to creat a new process with no or less sysmask protection. Among the three steps, while the first one is not so hard, the second is clearly much more difficult. Even the third step can be made no less difficult by a custom kernel recompile with code/data random shuffle (see the "future enhancements" section). To show how close step B is to practical impossibility, I have set up a security simulation page on http://wims.unice.fr/, that lets people simulate attacks with step A skipped off. That is, anybody can run arbitrary codes through the page, using either c, perl or sh, in order to break step B. You can regularly check the status of the page, and time will tell! ------------------------------------------------------------ In practice, there is also an important security prime before sysmask becomes widespread: most network attacks come from "script kiddies" executing generic exploits. These exploits will unsuspectedly suppose that all system calls are open. So they will fail when they encounter an unexptedly closed call. This security prime will even remain after sysmask is widespread, because masks are site-configurable, therefore it is not obvious to guess which services are still available for a given daemon and on a given site. ------------------------------------------------------------ This said, the actual security level of a system depends largely on its configuration, as sysmask can be configured anywhere from no protection at all (empty restriction everywhere) to extremely secure (everything is as tight as possible). Please refer to the other sections of this documentation as well as the template configuration to see how individual softwares can be configured. Here we simply note that many (if not most) of the individual security measures of various daemon softwares are clearly obsoleted by sysmask. Examples include smrsh for sendmail and chroot for opensshd, suexec for apache. Sysmask offers a uniform solution that is way more solid than these individual ad-hoc ones. On the other hand, these individual measures even often interfere with the configuration of sysmask, preventing it from taking the tightest restrictions. For example, if opensshd is not compiled with chroot, sysmask can mask chroot for it, while in any case file access is strictly controled by sysmask, except the most sensitive one (/etc/shadow) for which neither chroot nor sysmask can do anything until a redesign of the system authentication scheme. After the redesign, it is sysmask that will ensure that strictly nobody can steal the content of /etc/shadow. Therefore chroot offers no more protection beyond that of sysmask. There is only one system risk that is known to be unprotectable by sysmask without recompiling programs. It concerns systems with a running X server. In theory, a compromised user program may have the possibility to exploit a potential vulnerability in the X server, compromising it in turn. Now the latter has privileges to access all io ports of the system, that is, all the hardware of the system is at risk. ------------------------------------------------------------ Unprotect Linux is fundamentally insecure. Besides the constant flow of security alerts, nobody should be so naive as to believe that there is no vulnerabilities kept in secret. There are even indications that make me suspect the existence of trojan horses hidden in the kernel. The situation greatly changes under sysmask. With a properly configured sysmask protection, you know that but for a vulnerability of exceptional seriousness, no hacker will be able to break into your system, and no virus can get installed in a user account. So you can stop following security alerts (except those making headline news), stop using virus scanners, and stop updating your softwares every week. Stop updating softwares is not just a convenience. It is above all a necessity for security. And the worst thing is automated updates which will soon be among the biggest security breaches. Use sysmask to make sure that no one (except yourself, manually) is allowed to replace your system files!