LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityEnabling DRM in the kernel?Back in April, we looked at the Linux kernel patches for Intel's Trusted Execution Technology (TXT), a mechanism to verify the integrity of the kernel before booting it. Since that time, another version of the patchset has surfaced. The relatively few comments on the feature were largely concerned that there might be opposition to its inclusion—not because of technical considerations, but instead because of ethical concerns about what TXT could enable. Ted Ts'o had the most to say about what TXT (also known as LaGrande) enables, not necessarily in opposition to adding the feature, but outlining the concerns of those who might. He warned: "So we should expect a certain amount of controversy and people lobbying to resist the acceptance of this patch." The basic problem is that TXT can enable Digital Rights Management (DRM) systems that are largely uncrackable. Pointing to a "Trusted Computing" FAQ from 2003, Ts'o noted that five years ago, FAQ author Ross Anderson "was able to predict the emergence of the LaGrande Technology (see question 15 in the above FAQ)." But, Joseph Cihula, author of the TXT patch noted that some of the FAQ (and other Trusted Computing complaints) had been rebutted [PDF] in an IBM whitepaper by David Safford. But, as Ts'o pointed out, much of Safford's response was specific to the Trusted Computing Platform Alliance (TCPA) technology, which is essentially broken as a DRM lockdown solution:
However, it seems to me that TXT/LaGrande's main purpose for existence
was to repair the defects in TCPA that made it essentially [unusable]
for DRM purposes. With TCPA, any time you changed *anything* in the
boot path --- installed a new BIOS, upgraded to a new kernel to fix a
security vulnerability, updated to a new Nvidia proprietary video
driver slightly less likely to crash your [system] --- it would change
the trusted boot measurements, and would require an exchange to
"[Circuit] City DIVX hotline" (as a generic stand-in for whoever is
Hollywood's current monkey paw towards trying to implement DRM) to
approve a transfer of the TCPA trusted keys, which would be
essentially be a consumer support nightmare, and there would be no way
for "Circuit City" to know whether the kernel you are claiming was the
latest update from Fedora or Novell or Canonical was really an
authorized upgrade, or whether it was a custom kernel with patches to
tap into video and audio paths to steal Hollywood's precious bodily
fluids.
With TXT, however, all of these problems go away. What you end up booting is completely under "[Circuit] City's DIVX's" control, and may include a miniature Windows environment running in the trusted environment; it could then take over a portion of the screen for the video output, and the hardware would have special features set up to prevent the host OS from having any access to the video output of the movie player running in the TXT environment. Ts'o's message is worth reading in its entirety, but the basic point is that TXT enables Hollywood (or another DRM-happy entity) to take away some of the basic functionality of the hardware in order to preserve their "rights". Essentially, this takes away users' rights to protect companies' perceived or actual rights. The truly nightmarish scenario is one where one cannot do anything on a computer that isn't contained in a signed (presumably proprietary and closed source) application, running on a signed operating system. TXT could enable just that kind of functionality. But, there are some scenarios (Ts'o mentions medical record access) under which TXT could be beneficial to the user. Other devices (voting machines and ATMs are the standard example) could benefit from TXT as well. Should kernel hackers stand in the way of adding this code to the kernel simply because it can be used for ill? The consensus, from the extremely limited subset of the kernel development community participating in the discussion, seems to be "no". James Morris notes Linus Torvalds's famous "Flame Linus to a crisp!" message wherein he says: "I want to make it clear that DRM is perfectly ok with Linux!". Morris more-or-less agrees with that view:
I'm fairly neutral on the technology itself and feel that "market
pressure" from users as well as local regulatory policy (e.g. anti-trust
laws) should determine how the technology is used, rather than the views
of a few kernel hackers.
That sentiment is also shared by Ts'o: "That being said, it's not clear to me that stopping the technology from going into Linux really isn't going to help matters; realistically, the Linux desktop is miniscule[1], and whether or not we add support for TXT in the mainline Linux kernel isn't going to stop Hollywood's plans." His footnote refers to the potential risk of TXT being used in Moblin to lock down those devices, but "realistically, even if we don't let it into mainline kernel, it won't stop Moblin hardware vendors from shipping it". This is a social, not a technical problem, as Ts'o says. There are powerful interests that certainly want to have that kind of power over the actions of their customers. It will be up to those who value their hardware and software freedoms (and, very likely, the courts) to ensure that those freedoms are still available. Avoiding DRM is not something that has gotten onto the radar of most consumers, but the content providers are doing their best to raise its visibility. One wonders how many revoked features for Kindle books or how much music that expires because it is crippled with DRM it will take before consumers start to rebel. In the meantime, though, it seems likely that Linux will end up with TXT support somewhere down the road. The objections have been few—technical or ethical—at least so far, and the code obviously exists. There is no barrier to a hardware manufacturer (or distribution) incorporating it and enforcing whatever restrictions it wishes. Given that there are benign uses as well, the code is likely to improve from its inclusion in the mainline. When (almost certainly not "if") those uses turn towards total lockdown, it will be a social battle, on multiple fronts, to preserve the hardware and software freedoms we enjoy today.
New vulnerabilities cyrus-sasl: buffer overflow
drupal: cross-site scripting
giflib: several vulnerabilities
gnutls: incorrect certificate validation
ipsec-tools: denial of service
ipsec-tools: denial of service
kernel: privilege escalation
kernel: SELinux check bypass
nsd: buffer overflow
ntp: buffer overflow
phpmyadmin: multiple vulnerabilities
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||