Security
Seccomp: replacing security modules?
LWN recently discussed an enhancement to the seccomp mechanism which would allow applications to restrict their future access to system calls. By blocking off some calls altogether and by using simple, ftrace-style filters to restrict the possible arguments to other system calls, a process could construct a small sandbox which would constrain it (and its children) going forward. Getting support for new security mechanisms in the kernel is often a challenge, but not this time - almost all of the reviews are positive. The biggest complaint seems to be that the patches are not ambitious enough; at least one developer would like to see developer Will Drewry shoot for replacing the Linux security module (LSM) mechanism altogether.Ingo Molnar has been a supporter of this work; indeed, he suggested some of the ideas which led to the current set of patches. But he is now asking Will to be a bit more ambitious in his goals. Rather than act as a gatekeeper for system calls, why not implement the ability to hook into arbitrary kernel events and filter access there? Those who have watched Ingo over the last couple of years are unlikely to be surprised to see that he suggests hooking into the perf events subsystem for this task. Perf already allows an application to attach to events to get notifications and counts; adding per-process filter expressions, he suggests, is a natural evolution of that capability.
In other words, Ingo suggests dropping the current interface, which is implemented with prctl(), in favor of a perf-based (or, at least, perf-like) interface which could operate on kernel events. In principle, any software event that perf can deal with now (including tracepoints) could be used, but these events would have to be explicitly modified by kernel developers to enable this sort of "active" use. For events modified in this way, filters written in an expanded language could be provided by an application. See this message from Ingo for an example of how this sort of functionality might be used.
One of the biggest advantages of hooking to arbitrary events is that filters could be applied at the real decision points. A filter which allows access to the open() system call based on the name of the file being opened is not truly secure; the application could change the name between the pre-open() check and when open() actually uses it. Checking at a tracepoint placed more deeply within the VFS lookup code, instead, would block this sort of attack. A check placed in the right location could also be more efficient, replacing several checks at the system call level.
According to Ingo, there are a lot of advantages to providing this sort of capability. It would allow, for the first time, security policies to be set up by unprivileged applications; developers could thus take a more active role in ensuring the security of their code. The feature could be made stackable, allowing multiple application layers to add restrictions. In fact, he thinks it's such a great idea that he said:
Someday, he said, event-based filters could simply replace LSM which he blamed for a number of ills, including stalled
security efforts, desktop annoyances, infighting, fragmentation, and
"probably *less* Linux security
". Merging the code in its
current form, he said, would take away the incentive to go all the way, so
he'd like to see it reworked along these lines first.
Needless to say, this idea is not universally popular in the Linux security module community. James Morris supports the merging of the current patch, which, he says, is a good way to reduce the attack surface of the system call interface, but, he said, it is the wrong place for more serious security checks. Real security policies, he said, should be done at the LSM level. Eric Paris suggested that the filter capability should be implemented as an LSM, but he also pointed out a key weakness of that approach:
Getting application developers to make use of a Linux-specific security mechanism is already asking a lot. Getting them to use a mechanism which may or may not be present even on Linux systems is even harder; that may be part of why application developers have never really stepped forward to provide SELinux policies for their code. The filtering capability envisioned by Ingo would be part of the core kernel itself; that alone could help to make it the "single security model" that Eric was wishing for.
Any such outcome is to be found well in the future, though; there are numerous obstacles to overcome. The amount of work needed to implement this capability is not trivial. Individual tracepoints within the kernel would have to be evaluated to determine whether making them "active" makes any sense. Without a great deal of care, allowing applications to block operations within the kernel could well introduce security problems of its own. Based on past experience, the developers of the existing security mechanisms in the kernel might oppose the addition of an entirely new security-related framework. Even Linus, in the past, has been resistant to the idea of creating a single security policy mechanism for the kernel.
For the near future, Will has indicated that he will look at implementing the feature along the lines suggested by Ingo. Once some code is out there, developers will be able to see its implications and the debate can start for real. The chances of the discussion going on for some time are fairly good.
Brief items
Security quotes of the week
New vulnerabilities
acpid: denial of service
| Package(s): | acpid | CVE #(s): | CVE-2011-1159 | ||||||||||||||||
| Created: | May 16, 2011 | Updated: | May 31, 2012 | ||||||||||||||||
| Description: | From the Red Hat Bugzilla entry:
It was reported that acpid opened the UNIX socket that informs unprivileged processes about acpi evens in blocking mode. If an unprivileged process were to stop reading data from the socket, then after some time the socket queue fills up which would then lead to a hang of the privileged acpid daemon. The daemon will hang until the socket peer process read some portion of the queued data or the peer process exits or is killed. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
apr: denial of service
| Package(s): | apr | CVE #(s): | CVE-2011-0419 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | May 13, 2011 | Updated: | August 2, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mandriva advisory:
It was discovered that the apr_fnmatch() function used an unconstrained recursion when processing patterns with the '*' wildcard. An attacker could use this flaw to cause an application using this function, which also accepted untrusted input as a pattern for matching (such as an httpd server using the mod_autoindex module), to exhaust all stack memory or use an excessive amount of CPU time when performing matching. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
apturl: denial of service
| Package(s): | apturl | CVE #(s): | |||||
| Created: | May 17, 2011 | Updated: | May 18, 2011 | ||||
| Description: | From the Ubuntu advisory:
It was discovered that apturl incorrectly handled certain long URLs. If a user were tricked into opening a very long URL, an attacker could cause their desktop session to crash, leading to a denial of service. | ||||||
| Alerts: |
| ||||||
exim: arbitrary code execution
| Package(s): | exim4 | CVE #(s): | CVE-2011-1407 | ||||||||||||||||||||||||||||||||
| Created: | May 13, 2011 | Updated: | May 31, 2011 | ||||||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
It was discovered that Exim is vulnerable to command injection attacks in its DKIM processing code, leading to arbitrary code execution. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
flash-plugin: multiple vulnerabilities
| Package(s): | flash-plugin | CVE #(s): | CVE-2011-0579 CVE-2011-0618 CVE-2011-0619 CVE-2011-0620 CVE-2011-0621 CVE-2011-0622 CVE-2011-0623 CVE-2011-0624 CVE-2011-0625 CVE-2011-0626 CVE-2011-0627 | ||||||||||||
| Created: | May 13, 2011 | Updated: | May 18, 2011 | ||||||||||||
| Description: | From the Red Hat advisory:
Multiple security flaws were found in the way flash-plugin displayed certain SWF content. An attacker could use these flaws to create a specially-crafted SWF file that would cause flash-plugin to crash or, potentially, execute arbitrary code when the victim loaded a page containing the specially-crafted SWF content. (CVE-2011-0618, CVE-2011-0619, CVE-2011-0620, CVE-2011-0621, CVE-2011-0622, CVE-2011-0623, CVE-2011-0624, CVE-2011-0625, CVE-2011-0626, CVE-2011-0627) This update also fixes an information disclosure flaw in flash-plugin. (CVE-2011-0579) | ||||||||||||||
| Alerts: |
| ||||||||||||||
perl: denial of service
| Package(s): | perl | CVE #(s): | CVE-2010-4777 | ||||||||||||
| Created: | May 13, 2011 | Updated: | July 7, 2011 | ||||||||||||
| Description: | From the openSUSE advisory:
This update fixes a bug in perl that makes spamassassin crash and does not allow bypassing taint mode by using lc() or uc() anymore. | ||||||||||||||
| Alerts: |
| ||||||||||||||
perl-Mojolicious: cross-site scripting
| Package(s): | perl-Mojolicious | CVE #(s): | CVE-2011-1841 CVE-2010-4803 | ||||||||||||
| Created: | May 16, 2011 | Updated: | May 25, 2011 | ||||||||||||
| Description: | From the CVE entries:
Cross-site scripting (XSS) vulnerability in the link_to helper in Mojolicious before 1.12 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. (CVE-2011-1841) Mojolicious before 0.999927 does not properly implement HMAC-MD5 checksums, which has unspecified impact and remote attack vectors. (CVE-2010-4803) | ||||||||||||||
| Alerts: |
| ||||||||||||||
pure-ftpd: command injection
| Package(s): | pure-ftpd | CVE #(s): | CVE-2011-1575 | ||||||||||||||||
| Created: | May 13, 2011 | Updated: | May 31, 2011 | ||||||||||||||||
| Description: | From the openSUSE advisory:
Pure-ftpd is vulnerable to the STARTTLS command injection issue similar to CVE-2011-0411 of postfix. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
tor: multiple vulnerabilities
| Package(s): | tor | CVE #(s): | CVE-2011-0015 CVE-2011-0016 CVE-2011-0490 CVE-2011-0491 CVE-2011-0492 CVE-2011-0493 | ||||||||||||
| Created: | May 16, 2011 | Updated: | June 9, 2011 | ||||||||||||
| Description: | From the CVE entries:
Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha does not properly check the amount of compression in zlib-compressed data, which allows remote attackers to cause a denial of service via a large compression factor. (CVE-2011-0015) Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha does not properly manage key data in memory, which might allow local users to obtain sensitive information by leveraging the ability to read memory that was previously used by a different process. (CVE-2011-0016) Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha makes calls to Libevent within Libevent log handlers, which might allow remote attackers to cause a denial of service (daemon crash) via vectors that trigger certain log messages. (CVE-2011-0490) The tor_realloc function in Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha does not validate a certain size value during memory allocation, which might allow remote attackers to cause a denial of service (daemon crash) via unspecified vectors, related to "underflow errors." (CVE-2011-0491) Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha allows remote attackers to cause a denial of service (assertion failure and daemon exit) via blobs that trigger a certain file size, as demonstrated by the cached-descriptors.new file. (CVE-2011-0492) Tor before 0.2.1.29 and 0.2.2.x before 0.2.2.21-alpha might allow remote attackers to cause a denial of service (assertion failure and daemon exit) via vectors related to malformed router caches and improper handling of integer values. (CVE-2011-0493) | ||||||||||||||
| Alerts: |
| ||||||||||||||
wireshark: denial of service
| Package(s): | wireshark | CVE #(s): | CVE-2011-1592 | ||||||||||||||||
| Created: | May 13, 2011 | Updated: | June 7, 2011 | ||||||||||||||||
| Description: | From the CVE entry:
The NFS dissector in epan/dissectors/packet-nfs.c in Wireshark 1.4.x before 1.4.5 on Windows uses an incorrect integer data type during decoding of SETCLIENTID calls, which allows remote attackers to cause a denial of service (application crash) via a crafted .pcap file. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>