Security
LSS: Security modules and RPM
The RPM package format and tools have long supported SELinux, so that policies are configured and files get labeled correctly at installation time. But support for other security solutions, Smack for example, is lacking in RPM. Elena Reshetova presented some ideas for rectifying that in her presentation at the 2012 Linux Security Summit (LSS). By adding hooks into RPM processing, more Linux Security Modules (LSMs) or other security components could be supported.
Reshetova began with an overview of RPM. The format is used by multiple distributions, beyond just the Red Hat distributions where it began. SUSE/openSUSE, Mageia, Tizen, and others all use RPM.
RPM package installation has the notion of a "transaction", which encompasses all of the packages to be installed or removed in a single operation. Inside these transactions are the individual packages or "transaction elements". Dependency checking is done at the transaction level, so it is only done once. Scripts to run before the transaction starts and after it ends can be configured in a package specification.
![[RPM flowchart]](https://static.lwn.net/images/2012/rpm-slide-sm.png)
Installing each package entails a series of steps inside the transaction, starting with the optional signature verification. If that passes (or is turned off), then the "pre" script is run, the files are unpacked from the archive and installed, and the "post" script is run. As might be expected, there are a few other steps (e.g. initialization, cleanup), but, as depicted in a flowchart (seen at right), pre-unpack-post makes up the bulk of the processing.
When SELinux handling was added to RPM, it was done to set up and install the policies and label the files that get installed. That work was mostly done in the sepolicy RPM plugin using the existing RPM hooks. But some SELinux support is in the RPM core, including running the maintainer scripts (pre, post, and a few others) and doing some labeling tasks. The maintainer scripts are run using rpm_execcon() to set a particular security context before their execution.
When Reshetova and others working on Tizen started looking into adding Smack support for RPM, they realized it needed a more generalized security plugin interface. Smack requires setting up access control domains and rules on a per-package basis, but there are other security mechanisms that have needs as well. The security policy for a system or device might trust certain application repositories and only allow packages from those source to access "sensitive services". Integrity measurements may need to be bootstrapped, container configuration established, or seccomp() restrictions enabled, all of which could be handled by a generalized security plugin.
Currently, there are just a few hooks available in RPM: two before the pre-transaction script is run, one before the pre script, one after the post script, and a cleanup hook. Reshetova would like to work with the LSM developers to create an expanded set of hooks that will serve all of the LSMs (as well as the other uses). Making the hooks symmetrical, so that there are hooks both before and after transactions and package installation/removal, might be the starting point. Adding a hook to wrap script execution for setting up the proper security context is another.
Currently, the verification step only allows specifying which keys to use and what should happen if the package does not verify. Adding a hook for verification would allow for additional checking, such as that the package was signed by the right key (corresponding to the repository it came from, as opposed to any installed key, as RPM checks for currently), and to make security policy checks based on the originating repository.
The other hooks that Reshetova proposed are associated with the individual files in a package. Those would allow things like security labeling or calculating hashes on the file contents (for integrity purposes). The last hook she proposed is to handle conflicts. If a package wants to install a file that another package has already installed, the hook could install a conflict file recording the problem; later hooks could use that file to make decisions depending on the attributes of the two packages involved. If one package is from a more trusted repository, its version could be chosen, for example.
In addition, some environments may have non-native applications that use their own installer. Those have all of the same problems with handling security contexts, labeling, and so on. It would be nice to have the security plugin functionality available as standalone library that could be used by non-native application installers, Reshetova said.
Once those hooks (or a similar set that is agreed upon) are available, the SELinux-specific pieces of RPM could be moved out of the core. A unified layer of security hooks would be beneficial for a wide variety of use cases, she said. More information is available on the Tizen wiki and a GitHub repository contains the proposed changes for RPM.
Dan Walsh asked what the RPM maintainers thought about the changes; Reshetova said they are interested in seeing a unified solution. They want to make sure that there is agreement between the LSM developers, which is one of the motivations for her presentation. The intent would be to cause no disruption for the SELinux parts in RPM when moving that to the new hooks, she said in answer to another question. Walsh said that there really isn't anyone who is the "SELinux/RPM person", but he and others wouldn't oppose a patch to move SELinux out of the core; "don't break anything and I'm fine" with it, he said, though he did caution that performance might be an issue.
Since the summit, Reshetova has started a wider discussion of the hooks on the SELinux mailing list. It would seem likely that we will have a more generalized solution for RPM in the not-too-distant future.
Brief items
Security quotes of the week
This project strengthens the ludicrous idea in people's heads that photography is somehow a significant threat to safety or security. Photographic documentation is an extremely important part of modern democracy, and projects like these threaten the ability of people to take pictures.
Mozilla "Persona" beta release
Mozilla has announced the beta release of its "Persona" authentication system. "For the past year Mozilla has been working on an experimental login system that completely eliminates passwords on websites while being safe, secure, and easy to use. Today we’re casting off the 'experimental' label and announcing the first 'beta' release of Persona." LWN looked at this system in 2011, when it was still known as "BrowserID."
New vulnerabilities
apache: cross-site scripting
Package(s): | apache | CVE #(s): | CVE-2012-2687 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Created: | October 2, 2012 | Updated: | April 5, 2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Description: | From the CVE entry:
Multiple cross-site scripting (XSS) vulnerabilities in the make_variant_list function in mod_negotiation.c in the mod_negotiation module in the Apache HTTP Server 2.4.x before 2.4.3, when the MultiViews option is enabled, allow remote attackers to inject arbitrary web script or HTML via a crafted filename that is not properly handled during construction of a variant list. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
inn: man-in-the-middle attack
Package(s): | inn | CVE #(s): | CVE-2012-3523 | ||||||||||||
Created: | October 2, 2012 | Updated: | January 22, 2014 | ||||||||||||
Description: | From the Mandriva advisory:
The STARTTLS implementation in INN's NNTP server for readers, nnrpd, before 2.5.3 does not properly restrict I/O buffering, which allows man-in-the-middle attackers to insert commands into encrypted sessions by sending a cleartext command that is processed after TLS is in place, related to a plaintext command injection attack, a similar issue to CVE-2011-0411 (CVE-2012-3523). | ||||||||||||||
Alerts: |
|
kernel: information leak / denial of service
Package(s): | kernel | CVE #(s): | CVE-2012-3510 | ||||||||||||||||||||||||||||||||||||||||||||
Created: | October 3, 2012 | Updated: | October 24, 2012 | ||||||||||||||||||||||||||||||||||||||||||||
Description: | From the Red Hat advisory:
A use-after-free flaw was found in the xacct_add_tsk() function in the Linux kernel's taskstats subsystem. A local, unprivileged user could use this flaw to cause an information leak or a denial of service. | ||||||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
mod_rpaf: denial of service
Package(s): | mod_rpaf | CVE #(s): | CVE-2012-3526 | ||||
Created: | September 28, 2012 | Updated: | October 3, 2012 | ||||
Description: | From the Gentoo advisory: An error has been found in the way mod_rpaf handles X-Forwarded-For headers. Please review the CVE identifier referenced below for details. A remote attacker could send a specially crafted HTTP header, possibly resulting in a Denial of Service condition. | ||||||
Alerts: |
|
moodle: multiple vulnerabilities
Package(s): | moodle | CVE #(s): | CVE-2012-4400 CVE-2012-4408 CVE-2012-4402 CVE-2012-4403 | ||||||||
Created: | September 27, 2012 | Updated: | October 3, 2012 | ||||||||
Description: | From the Red Hat Bugzilla entries [1, 2, 3]: CVE-2012-4400: A possibility to bypass file upload size constraint was found in the way the webservice script, called from the filepicker front end of Moodle, a course management system, performed sanitization of 'maxbytes' variable. A remote attacker could issue a specially-crafted request that, when processed could allow an attacker to upload a file even if it was larger than specified constraint. CVE-2012-4402, CVE-2012-4403: Users with permission to access multiple services were able to use a token from one service to access another. An attacker could use this flaw, in an unauthorized way, to access content of an external service. CVE-2012-4408: A security flaw was found in the way Moodle course management system performed permission check on course reset page (the course reset link was protected by a correct permission, but the reset page itself was being checked for a different permission). A remote attacker could use this flaw to in an unauthorized way to reset particular course. | ||||||||||
Alerts: |
|
moodle: multiple vulnerabilities
Package(s): | moodle | CVE #(s): | CVE-2012-4401 CVE-2012-4407 | ||||
Created: | September 27, 2012 | Updated: | October 3, 2012 | ||||
Description: | From the Red Hat bugzilla entries [1, 2]: CVE-2012-4401: A security flaw was found in the way Moodle course management system performed user permissions validation by course topic management. A remote attackers, with course editing capabilities, but without ability to show / hide topics or set the current topic for a particular course could use this flaw to successfully complete these actions under certain circumstances. CVE-2012-4407: A security flaw was found in the way file serving functionality of Moodle course management system enforced file access restrictions on blog post(s). A remote attacker could use this flaw to deliver files embedded as part of a blog without the publication state to be checked properly. | ||||||
Alerts: |
|
postfixadmin: multiple vulnerabilities
Package(s): | postfixadmin | CVE #(s): | CVE-2012-0811 CVE-2012-0812 | ||||||||
Created: | September 27, 2012 | Updated: | March 28, 2014 | ||||||||
Description: | From the Gentoo advisory: Multiple SQL injection vulnerabilities (CVE-2012-0811) and cross-site scripting vulnerabilities (CVE-2012-0812) have been found in Postfixadmin. | ||||||||||
Alerts: |
|
software-properties: man-in-the-middle attack
Package(s): | software-properties | CVE #(s): | |||||
Created: | October 2, 2012 | Updated: | October 3, 2012 | ||||
Description: | From the Ubuntu advisory:
It was discovered that the apt-add-repository tool incorrectly validated PPA GPG keys when importing from a keyserver. If a remote attacker were able to perform a man-in-the-middle attack, this flaw could be exploited to install altered package repository GPG keys. | ||||||
Alerts: |
|
tor: denial of service
Package(s): | tor | CVE #(s): | CVE-2012-4922 | ||||||||||||
Created: | October 2, 2012 | Updated: | February 4, 2013 | ||||||||||||
Description: | From the CVE entry:
The tor_timegm function in common/util.c in Tor before 0.2.2.39, and 0.2.3.x before 0.2.3.22-rc, does not properly validate time values, which allows remote attackers to cause a denial of service (assertion failure and daemon exit) via a malformed directory object, a different vulnerability than CVE-2012-4419. | ||||||||||||||
Alerts: |
|
vmware-player: multiple vulnerabilities
Package(s): | vmware-player | CVE #(s): | CVE-2007-5671 CVE-2008-0967 CVE-2008-1340 CVE-2008-1361 CVE-2008-1362 CVE-2008-1363 CVE-2008-1364 CVE-2008-1392 CVE-2008-2098 CVE-2008-2100 CVE-2008-2101 CVE-2008-4915 CVE-2008-4916 CVE-2008-4917 CVE-2009-0909 CVE-2009-0910 CVE-2009-1244 CVE-2009-2267 CVE-2009-3707 CVE-2009-3732 CVE-2009-3733 CVE-2009-4811 CVE-2010-1137 CVE-2010-1138 CVE-2010-1139 CVE-2010-1140 CVE-2010-1141 CVE-2010-1142 CVE-2010-1143 CVE-2011-3868 | ||||
Created: | October 1, 2012 | Updated: | October 3, 2012 | ||||
Description: | From the Gentoo advisory:
Multiple vulnerabilities have been discovered in VMware Player, Server, and Workstation. Local users may be able to gain escalated privileges, cause a Denial of Service, or gain sensitive information. A remote attacker could entice a user to open a specially crafted file, possibly resulting in the remote execution of arbitrary code, or a Denial of Service. Remote attackers also may be able to spoof DNS traffic, read arbitrary files, or inject arbitrary web script to the VMware Server Console. Furthermore, guest OS users may be able to execute arbitrary code on the host OS, gain escalated privileges on the guest OS, or cause a Denial of Service (crash the host OS). | ||||||
Alerts: |
|
xdiagnose: insecure temp files
Package(s): | xdiagnose | CVE #(s): | |||||
Created: | October 3, 2012 | Updated: | October 3, 2012 | ||||
Description: | From the Ubuntu advisory:
Alec Warner discovered that xdiagnose improperly handled temporary files in welcome.py when creating user-initiated archive files. While failsafeX does not use the vulnerable code, this update removes this functionality to protect any 3rd party applications which import the vulnerable code. In the default Ubuntu installation, this should be prevented by the Yama link restrictions. | ||||||
Alerts: |
|
Page editor: Jake Edge
Next page:
Kernel development>>