LWN.net Weekly Edition for February 28, 2013

SCALE: Developing a project community

The day before SCALE 11x in Los Angeles was devoted to a series of mini-summits; some centered around a single software project (such as Puppet or Ubuntu), but others were topical—such as the FOSS Mentoring summit. That summit was devoted to the mechanics of working with the human aspects of a free software project, from developers to end users. For example, Nathan Betzen of XBMC discussed the communication tools, from forum packages to external social networking services, and how the project makes use of each. Karsten Wade spoke about infrastructure volunteers (e.g. as system administrators), and how to recruit, train, and foster increased participation. Robyn Bergeron spoke about organizing and managing predictable release cycles in a project that relies on unpaid—and often hard-to-predict—volunteer contributors.

Communication tools

Betzen has been working with XBMC since 2008, and currently serves as community manager. His talk dealt with end-user-facing tools—blogs, forums, and so forth—as distinguished from development-centric tools like source code management or build systems. In large part, he said, this is of interest because XBMC is a user-facing application with a large community of users who are not engaged in software development.

He started off with general advice on "how not to suck" at user community interaction. This advice included sincerity in messaging (communicating why you honestly feel your project is great, rather than crafting an artificial message), restricting your posts to appropriate and relevant information (regardless of how awesome your cat photos may be), and seeking relevant input from the users. On that point, he said that starting an open source project is a public statement that you expect other people will want to work on the product. The earlier you accept that—including the fact that these others will bring different opinions and plans—the better your communication will be.

He then summarized the most common avenues for user communication, and what XBMC has learned about their suitability for different purposes. Web-based discussion forums are the "heart" of your community, he said: where everyone is going to go to talk to and ask questions of the development team, and where they will look for help. He gave no advice on the specific software package used, but said the important thing is that users can register and write their words on your footprint on the Internet. He gave some "best practices" advice, such as trying to shut down as few threads as possible (other than lawbreaking topics and bots). Even if your community becomes known for its off-topic discussions, people are still coming to the site and learning about your software. He also advised making forum rules early (and making them highly-visible), and making as much intra-team communication open as possible, even if that only means posting read-only threads summarizing team meetings.

Blogs are distinctly different from forums as a community tool, Betzen said. If comment threads on individual posts are the only place where discussions occur, the project suffers. First, individual posts come and go (including going off the bottom of the first page rather fast), and blogs allow only site administrators to start a topic of discussion. That prevents community members from speaking what's on their mind, plus it creates a bottleneck. "You want as many people as possible to do the work of making conversations."

He then discussed the relative pros and cons of the current social networking services, starting with "the great beast," Facebook. Facebook is a "not terrible" way to gauge the reach of your project, he said, and is considerably better than log-based web analytics. The reason is that every Facebook account is bound to a real person. Thus, in addition to calculating your own project's reach, you can compare it to the reach of your competitor projects. It is also a useful outreach tool, since it is one of the default places people unfamiliar with your project start a lot of their searches. It works well as a "personality outreach" tool, where you can ask end users to submit ideas and content of their own. For example, he said that XBMC regularly asks users to post photos of their own XBMC systems, and frequently gets submissions for themes, mascots, and other mock-up designs that eventually become reality.

In contrast to Facebook, Betzen said, Twitter is a terrible way to measure reach, since it is dominated by fake accounts and bots. "Half the people on Twitter aren't real people," he said. "You can become a 'Twitter master' with thousands of followers, most of whom don't know who you are and aren't even real." Still, he said, it functions well as a front-line support service, and is useful to visibly communicate with non-users and participate in the larger world.

Reddit can be a good tool, he continued, but it really works best for already-engaged projects. He advised against creating your own "subReddit," since that can be seen as self-aggrandizing, but added that the site can be useful as a persistent news outlet and to promote "causes" and campaigns. For example, he cited the case of a third-party port of XBMC to the original Xbox hardware: when PayPal unilaterally shut off the group's donation account without explanation, a Reddit furor arose that was credited for PayPal's decision to mysteriously reinstate the account (again without explanation).

Finally, he discussed Google+ and YouTube. Google+ is popular among developers but not with users, yet it has a killer feature with the "Hangout" video chat system. This allows people to talk directly to a project team, which is a great way to engage, and it can be used to broadcast live meetings. Similarly, YouTube videos offer some "magic", because there are frequently features or procedures that are clear in a screencast, but terrible to try to read on a "list of steps that was written on a wiki several years ago and hasn't been updated."

Infrastructure

Wade's session also dealt with the practicalities of managing a project, in particular how to organize and maintain infrastructure: the systems administration and support tasks that keep a project functioning smoothly (as opposed to the development of the actual code). He highlighted the importance of treating infrastructure as an avenue of open participation, just like hacking.

Wade's advice had two sides. First, using open tools protects the project (in that owning your data and other "stuff" is critical), and it allows other open projects to see how you do things and learn from them. Second, making infrastructure participation part of the project gives interested administrators a way to pitch in and support the project even if they are not prepared to be developers and (as with coding) it offers a good way for those interested in systems administration to learn and equip themselves with skills that will be valuable later.

He drew examples from his experiences on the Fedora distribution and on the oVirt project. The first piece of advice was to divide project infrastructure into three categories: core-essential, core-nonessential, and non-core. Core-essential pieces are those that are required to actually develop the software, such as source code management, build systems, and testing tools. Core-nonessential pieces are those necessary to keep project participation functioning, but are not related to the project code itself, such as configuration-management tools or mailing list software. Non-core pieces are those concerned with data and metadata, and are generally orthogonal to the system on which they run, such as wikis, documentation, and blogs.

These categories should be treated separately, he said, and doing so benefits both administrators and developers. Developers may prefer to take care of the core-essential pieces themselves, but they do not need to take time setting up Mailman configuration or provisioning database servers. Administrators, too, can divide up tasks in the layers, letting go of control "down to the bare metal" as administrators often want.

Wade instead advised projects to treat the "holy grail" of administration—root access on the server—just like it does the holy grail of development, commit access. By starting new infrastructure volunteers on non-core tasks (even wiki maintenance or web page editing), they can learn the system, gain experience and the trust of other administrators, and work their way toward the core systems. Having a transparent process and meritocractic system are ideals that define open source projects, he said, and they apply to infrastructure administration just as they do to anything else.

A lot of administrators treat the prospect of sharing root access warily, since it is tricky to trust volunteers that they have never met in person. But Wade argued that such trust-building is no different than the trust-building process required of new developers. It is just a mindset many administrators have not adopted. Projects can and should consider sandboxing systems and other tools to guard against accidental catastrophes, but ultimately administrators need to remember that systems administration is not a life-or-death endeavor, and if someone on the team does make a mistake, the project can always roll back the change. Of course, that advice does assume that the project is keeping backups, but that is hardly a new piece of advice.

He also offered several practical ideas for projects looking to get their infrastructure into better shape. The first is to start small and scale up as the project grows. Initially, the bare minimum that the project requires will have to do, even if that is a bargain-rate web hosting plan. The second idea is to find ways for interested sponsors to contribute to the infrastructure as a means of supporting the project. Providing tools or covering all or part of the hosting bills is a good way to let companies visibly support the project, and by allowing multiple companies to contribute, it shows that the project has broad support (as well as giving all vendors equal opportunities). He mentioned that several companies provide servers to the Fedora project; whichever one is responsible for serving up a particular page is indicated on the page itself.

Finally, he provided specific examples of how the oVirt and Fedora projects each split up their infrastructure organization. Fedora's core-essentials include the Koji build system, pkgDB database, Bodhi updater, Yum update system, source code management, testing infrastructure, and "Fedora people" web pages (the latter because they are sometimes used to provide package repositories). Fedora's core-nonessentials include Bugzilla, MediaWiki, WordPress, Planet, elections infrastructure, and mirror management system. The non-core pieces include web hosting and FTP mirroring. The oVirt core-essentials are fewer in number: Git, Gerrit, Jenkins, and Yum. Its core-nonessentials include Puppet, Foreman server manager, and Mailman. Its non-core pieces include MediaWiki and to some extent Mailman (here Wade observed that sometimes the borders between the layers can be fuzzy), and external services like GitHub and Identi.ca.

The audience asked several questions, such as how IRC fits into the mix. Wade replied that IRC is a tricky one, since it is used for communication but is also integral to the development process. The projects tend to use external IRC networks like OFTC and Freenode, but run their own logging and announcement bots (which he considers pieces of project infrastructure). Another audience member suggested that "core" and "essential" might be taken as loaded words, which Wade readily conceded (who wants to hear they have been deemed nonessential, after all?). He said he was open to better suggestions, but that the principle of layers and levels was the main point.

Release cycles

Bergeron discussed "project management" in what she called the classical, business-lingo sense—specifically, addressing the questions of "how do we get this puppy out the door on time?" and "how do we juggle the logistics?" In the business world, there are project management certifications and training classes, she said, but none of them talk about how to apply their tactics to the open source approach, which has peculiarities. First, open source projects are composed of many people (often even critical team members) who are volunteering their time, and cannot be dictated to like a salaried employee. Second, such projects must cope with constant uncertainty in turnover, such as people changing jobs, going away to college, or losing interest for other reasons. Bergeron offered her own advice on this type of project management based on her experiences as Fedora project leader, specifically with regard to managing a development and release cycle.

The first piece of advice is to have a schedule. Shipping on time is the holy grail, she said, but it is important to recognize that shipping on time at the cost of angering and demoralizing the project's members is not worth it—ideally, you want your project to grow continually. How the schedule is determined needs to scale with the project, as does how it is communicated to project members as a whole. For a three-person team, putting it on a single web page may be sufficient; for a large project it is not. It does, however, actually need to be published somewhere. Mentioning it in a blog post is not good enough, as eventually it will scroll off the bottom of the page.

The next piece of advice is to communicate everything. A lot of people assume that open source projects are constantly communicating, but there are things every project can do better. In brief, she said, you cannot remind anyone too frequently about anything. But clarity is the key, so although important things like the schedule need to be communicated broadly to avoid the "well nobody told me about that" problem, they also need to be published in a consistent, predictable manner. In other words, emailing it and posting it at wiki/Schedule one time, then blogging it and posting at wiki/Calendar the next is a bad idea. An audience member asked how to communicate constantly without it becoming annoying; Bergeron replied that that was a risk but it could be mitigated with a good tone and a smile.

The next piece of advice is to manage how much work takes place during the release cycle. Projects need to agree on what features and changes will receive attention, and not simply let everyone do whatever they want when they want to do it. But these plans also need to consider failure a possibility, and plan for incomplete efforts and how to roll back changes. Change-planning can be contentious, she said, but it is critical that the project have the conversations in the community, or else people will leave. Sometimes people hear that warning and think "I want X to leave, he's a damn fool," she said, but you never know who he will take with him or where he might go.

The fourth piece of advice is to learn to live with Murphy (as in Murphy's Law). Problems will happen, she said, but when they do they usually contain learning opportunities. In addition, coming through the problem together can be good for the community, as it fosters a sense of camaraderie. The final piece of advice was to consciously set expectations for each cycle. The best way to do that is to be transparent about the decision-making process and to be communicative. Surprises can scare people off, she said, but invitations to help out are awesome.

In the audience question-and-answer session, one person asked what tools there are for project management. Bergeron recommended TaskJuggler, among other open source options. Another audience member asked how projects can prevent "collisions" where more than one person wants to work on the same thing. Bergeron replied that Fedora has several teams that collaborate, which is one way to tackle the problem, but added that it was rarely a practical concern. Most of the time, there is far more work needing to get done than there are volunteers to do it.

All three sessions provided practical advice, and, judging by the number of audience questions (of which only a fraction were recounted above), that advice was useful for quite a few attendees. Since the free and open source software ecosystem is one that exists to produce software, it can be all too easy to spend too much time thinking about revision control systems and contributor agreements and conclude that those topics cover what it takes to manage a successful project. But as Wade said, what really makes a project "open" is how it functions, not what license it uses; that applies to communication, infrastructure, and scheduling just as it does to development.

Comments (6 posted)

SCALE: 3D printing and the early days of Linux

Kyle Rankin is a systems administrator by trade, but a 3D printing aficionado by hobby. At SCALE 11x in Los Angeles, he presented the Sunday morning keynote address, which looked at the history and present circumstances of the 3D printing movement—and drew parallels with the rise of Linux.

Rankin described himself as a "software guy" not a hardware hacker, a fact that slowed down his entry into the 3D printing world, where most projects demand quite a bit of fabrication and soldering-iron skill. In many of his other hobbies, he said, he ends up using a Raspberry Pi or other embedded Linux systems instead of the more common Arduino microcontroller, since he can solve his problems with software. Consequently, he followed the home 3D printer world for more than a year before finding the right product and making a printer purchase. That purchase was a Printrbot, an open hardware printer that includes pre-assembled electronics.

Apart from finding the right hardware, Rankin said a big challenge to getting started with 3D printing was justifying the up-front expense to his wife's satisfaction. Initially this was a big obstacle, he said, because the only answer to the question "So what can you make with a 3D printer?" seemed to be "parts for another 3D printer." As time went on, however, the array of printable object possibilities broadened, including hard-to-find parts for fixing broken appliances, household tools and objects, and baby toys.

How did we get here

Rankin then outlined the history of the home 3D printing movement, which he said included a number of parallels to the growth of Linux. For example, initially 3D printing was the exclusive domain of high-end devices costing hundreds of thousands of dollars, and affordable only to corporations. But as happened with "Big Iron" Unix, eventually lower cost devices (under US $30,000) became available at universities, at which point do-it-yourself-ers began asking themselves whether they could build similar systems at home.

In 2004, Adrian Bowyer announced the RepRap project, which Rankin said was akin to Linus Torvalds's initial post to comp.os.minix announcing Linux. RepRap was designed from the beginning to be an open source software and hardware project to create a 3D printer that could be built by anyone, without the need for specialty materials—any parts that were not easily available off-the-shelf must be printable with a RepRap itself. As the project picked up speed, Rankin said it evolved into the Debian of 3D printing, thanks in large part to its commitment to avoid parts that were only available in certain regions.

In 2006, a RepRap device first printed a workable part for another RepRap, and in 2007 the first device printed a complete set of RepRap parts. Around this same time, community members started up side businesses printing and selling these parts, which Rankin likened to the Linux CD-pack businesses of the 1990s. In 2008, early adopter Zach Smith founded Thingiverse, a site for publishing and sharing 3D printable object models; the site proved to be the most important contribution to the 3D printing movement since RepRap. In 2009, Smith and others founded MakerBot, a for-profit company centered around selling open source 3D printers, which Rankin said was akin to Red Hat's foray into building a commercial business around a Linux distribution. Like Red Hat Linux, derivatives began to appear, such as the modified versions of Makerbot printer kits sold by Makergear.

Over the following years, the designs and capabilities of 3D printers evolved rapidly. The RepRap Prusa Mendel was released in 2010, with noticeable improvements in simplicity and buildability over earlier designs—to the point where the Mendel is still the most popular RepRap model today. In 2011, Printrbot appeared on Kickstarter, with a funding goal of US $25,000. Printrbot's aim was to create an end-user focused printer that was easier to build and use than the earlier designs, with the motto "a 3D printer in every home." Rankin compared this to Ubuntu with its emphasis on creating a quality end-user experience. Like Ubuntu, Printrbot proved popular, ultimately raising US $830,000 and starting a deluge of 3D printer–related Kickstarter projects.

December 2011 saw the release of the RepRap Mendel Max, which was built on a tougher aluminum extrusion frame, which enabled significantly faster printing by eliminating vibrations. In early 2012, Makerbot revealed another leap forward, with a dual-extrusion option for its Replicator printer. Dual-extrusion printing allowed for cosmetic options like multi-color prints, but it also allowed users to print different types of objects (such as by using one print head to print "support structures" in a water-soluble plastic). In September, however, Makerbot announced that it was taking its printers closed source to combat against clones. Around the same time, Thingiverse (which is owned by Makerbot) changed its terms of service to say that it owned all user-uploaded designs.

There was backlash against both moves. Rankin compared it to the backlash against Red Hat when it stopped providing public downloads of its distribution and began taking trademark action against people who redistributed Red Hat clones. The 3D printer community backlash was greater against Thingiverse, he said, including an "Occupy Thingiverse" movement spearheaded by Josef Prusa (who created the popular Prusa Mendel model of RepRap). The Occupy Thingiverse movement flooded the site with a manifesto document written by Prusa, which can still be found in many Thingiverse design searches today.

3D printing today

Rankin concluded his talk by describing the current state-of-the-art in 3D printing. He compared the most recent models from most of the vendors in terms of size, cost, and printing specifications. Prices continue to drop for the hardware, he noted, but ironically the cost of the plastic filament used for printing has shot up considerably—primarily because investors in the plastics futures market saw the rise of 3D printing coming and bought into it to turn a profit.

Nevertheless, Rankin described several recent changes that make the investment in a printer worthwhile. Ease-of-use has improved markedly, he said. Again comparing it to the Linux world, he said today it is no longer necessary to call the local 3D printer expert to guide you through the build process, much like the days when one had to go to an "install fest" to get Linux installed and a working xorg.conf file crafted. There are also more interesting designs for printable objects. He showed a set of LEGO block designs collected from the now–public domain specifications of the original LEGOs, plus an array of connectors for joining LEGOs to other brands of blocks. There are also extremely high-quality toy designs available for printing now, such as the elaborate fairytale castle set and a wide range of Nerf weaponry.

But 3d printing technology is still marching forward. Current work focuses on increasing print speeds and finer print resolutions, but there are other interesting projects in the works, too. One is the effort to create a cheaper alternative to the now-expensive plastic filament used as printing material. The Filabot project attempts to grind up recyclable plastic into usable filament, albeit with less-than-perfect success so far, while the company Formlabs has been working on a desktop printer that uses stereolithography to print, eschewing plastic filament altogether. The next big topic for research is 3D scanning, Rankin said; if affordable 3D scanners become a reality, people will be able to print solid objects without ever touching modeling software—or perhaps "3D fax" machines will arise.

Finally, there are controversies to expect as 3D printing becomes even more mainstream. One is copyright and patent law; as more and more objects become reproducible without permission, people should expect businesses to make moves to try and protect their revenue streams. Rankin noted that some 3D-printable materials can be used to make molds as in lost-wax casting; this means functional metal objects are possible, which are a more likely source of copyright and patent contention. They may also raise legal questions: Rankin cited the case of a Thingiverse user last year who posted models that could be used to print firearm parts, including the lower receiver—which the US government considers the "actual" gun (and is where serial numbers are located). The designs were taken down by Thingiverse, but as is always the case on the Internet, they are still available elsewhere.

Home 3D printing remains largely a hobbyist activity today, but the comparison to Linux is an eye-opening one. Linux, too, started off as a hobbyist project, and it grew quickly to dominate computing. Rankin emphasized that open source software powers most of the current 3D printing revolution, from hardware designs to modeling to driving the printers. It may still have a ways to go, but for a movement less than a decade old, its progress is already remarkable.

Comments (1 posted)

SCALE: Marshmallow on Raspberry Pi

Developers have used the diminutive Raspberry Pi as a platform for an assortment of computing tasks, but one of the most popular tasks has been entertainment—including video gaming. At SCALE 11x in Los Angeles, developer Guillermo Antonio Amaral Bastidas presented his work on the Marshmallow Entertainment System (MES), a retro-styled video game engine for 8- and 16-bit, 2D games. He compared MES to the competition (both open and closed) and explained what he has learned along the way.

Heroes and villains

Amaral does not simply talk the talk; his presentation was delivered in the form of a 2D side-scrolling MES game in which he navigated a character (which looked like him) through a game world—a world in which his text notes were embedded in a obstacle course (and, in some cases, floating by like clouds). He started off with a rundown of the other "open-ish" game consoles, comparing their openness and their specifications (both hardware and software).

The first was the Uzebox, a do-it-yourself retro gaming console based on an AVR microcontroller. The Uzebox offers little in the way of power, running at 30MHz, but it is 8-bit native, so game designers can build actual 8-bit, "Nintendo-style" games with the project's software development kit (SDK). The SDK includes a clock-perfect emulator, which is vital for testing games during development, and the project is completely open: open software and firmware, plus full hardware schematics. It may lack power, but Uzebox is also very affordable at US $60.

The GP2X is a slightly more powerful device designed as a handheld akin to the PlayStation Portable. It runs at 200MHz, which Amaral described as "mid-range" for such a system, and it is marketed as a ready-to-use consumer device. The SDK is open source, but Amaral said he was still unsure about the openness of the hardware. The GP2X is sold only in South Korea, so it can be difficult (and expensive) to find in other regions.

There are several Android-powered gaming devices on the market, he said, such as the Ouya and the GameStick. Both are very powerful, particularly for their price points (around US $80 for the GameStick, $100 for the Ouya, which is currently in pre-order). But they are both designed to play only Android games. So far, emulators have been promised but are not yet available. Amaral said he does not trust Android emulators to deliver a clock-perfect emulation environment, which should concern game developers. Both projects describe their SDKs as open source, but he said it was not clear exactly which components are available under an open source license and which are not. The hardware is proprietary for both products.

The challenger

MES has been two years in the making, he said. The early work was done on BeagleBoard and PandaBoard hardware, with the goal of creating a miniature game-focused distribution that anyone could download and run from a memory card on an off-the-shelf product. The BeagleBoard and PandaBoard were eventually discarded as being too slow at graphics, at which point he turned his attention to pre-release Raspberry Pi hardware. The Pi was an excellent fit because it can be safely overclocked to 1GHz, developers can write games for it in pure C++, and because it introduces few dependencies. He spent a considerable amount of time building the MES engine, plus the time required to get the Raspbian distribution into a workable shape (which included getting Qt4 running).

Lest there be any doubt, MES is entirely open source. It includes the stripped-down version of Raspbian which is focused solely on launching the Marshmallow game engine. He had initially intended each MES game to be installed on a separate SD card, so that they would be swapped in and out like the cartridges of 8-bit era game consoles. But the final builds used up just 110MB (for the OS and game engine), so he now recommends people install as many games as they want on a single card. The OS image uses a modified version of Buildroot and launches into a game selector screen. Amaral described the game selector as a work in progress, but the modified version of buildroot and other changes are all available on his GitHub repository.

During the development process, Amaral learned a few things about developing for the Raspberry Pi that he had not anticipated. The graphics capabilities are "awesome," he said, to the point where MES runs better on the Raspberry Pi than it does on his laptop. It even runs fine on the open source video driver, for those who do wish to avoid binary blobs. But audio support was less pleasant. The device supports both pure ALSA and OpenAL, but OpenAL runs too slowly to be useful. On the other hand, ALSA support was unsatisfactory as well; the device supports opening only one audio channel at a time. To get around this limitation (to, for example, provide background music as well as sound effects), Amaral wrote his own software audio mixer for MES.

A development wrinkle of a different sort is the Raspberry Pi's power cycling. The device has no reboot switch; it starts up when power is connected, and shuts off when it is removed. That can be annoying if using the device as a game system; more so while developing for it. To work around this problem, he designed an add-on board that sports a hardware reboot-switch. The board is called the Raspberry Pi Power Button, and the MES project sells it as a fundraiser, though the schematics are free on Amaral's GitHub site and anyone can build their own.

MES is just getting started as a game development platform. He described the engine as being "its own SDK," but so far there is not much in the way of a development guide. The SD card images come with a single demo game—though Amaral said he repeatedly encourages fans to contribute more to the game. The platform is BSD licensed, a decision he hoped would appeal to many independent game developers hoping to make products. Despite the newness of the platform, he said three gaming companies have contacted him to test it out, as well as attention from open source software and open hardware circles.

Raspberry Pi devices are a popular topic on the conference circuit these days, especially for gaming. But the most common gaming experience seems to be resurrecting 80's and 90's–era proprietary games for their nostalgia value. While that is certainly a source of entertainment, writing original games is more interesting, and MES shows that they can still provide that 8-bit retro feel, without the hassle of finding a legally-questionable ROM image from an old, commercial game.

Comments (16 posted)

Page editor: Jonathan Corbet

Security

ABS: Android security underpinnings

In a two-hour session at the 2013 Android Builders Summit, Marko Gargenta described the "underpinnings" of Android security. It was a wide-ranging talk that filled in many details of the Android security model and its implementation. There are multiple layers in the Android stack, Gargenta said, showing a slide [JavaScript] of the Android architecture. He broke the stack up into four layers: kernel, native code, API, and apps. Each of those has its own security concerns, he said.

Apps

In the Android security architecture, apps cannot directly interact with each other, nor with any of the other processes on the system. Those other processes come about as the Android system is initialized. After the kernel boots, init launches a few daemons needed by the rest of the system (vold, netd, installd), then starts the servicemanager. In turn, the servicemanager launches zygote, which is the "initial app" and the root of the app tree. All of those processes run as the root user, but anything started after that (including the system_server and any apps) run under its own user ID (UID).

Each app runs in its own process, and by default is not allowed do anything to adversely affect any other app, the system, or the user. That separation is enforced by the kernel's normal user permissions. On top of that, Android adds a fine-grained permission system that allows users to grant specific privileges to apps, but the apps must declare the privileges they want ahead of time.

Apps can explicitly share resources and data with other apps via the binder inter-process communication (IPC) mechanism, ContentProviders, Intents, the filesystem, local sockets, and so on. That sharing is outside of the scope of the Android security model. All apps are treated equally by the system, with the same level of application sandboxing.

The sole enforcement mechanism for the application sandbox is the Linux kernel. The Dalvik virtual machine (VM) does not provide a security boundary (unlike the Java VM). Each app has its own Dalvik VM as well as all the Android resources (activities, services, receivers, providers, etc.) in its process space.

Apps are stored in a .apk files, which must be signed. The signature is meant to uniquely identify the owner of the app, but that doesn't necessarily translate to a real life entity. It is, instead, used to create a trust relationship between apps. The signature is also used to verify that the contents of .apk file have been correctly signed with the owner's key and have not been corrupted.

App signing uses public-key cryptography as defined by the Java JAR specification. Most developers will already have a key that was created by Eclipse and lives in .android/debug.keystore. The keytool utility should be used to create a more permanent keystore. No third party certificate authority (CA) is needed for signing the keys as they can be self-signed. Google Play store policy for apps requires a key that is valid until at least October 2033, but keys should be valid for 25 years or more, Gargenta said.

Once an app is signed, it is "zipped" into a archive file, which is essentially what an .apk is. Each file in the zip archive is individually signed, and those signatures are stored in a file in the META-INF directory. The .apk contains the classes, resources, and the manifest, along with META-INF. One can use jarsigner to sign the files, and keytool to verify keys and signatures.

The platform itself has four different keys, which are often overlooked by people creating their own ROM. There is a "platform" key used to sign the core frameworks, a "shared" key for ContentProviders, a "media" key for the media frameworks and applications (e.g. Gallery, DrmProvider), and a "testkey" for everything else. Those can be created using keytool. Shipping a ROM with the default keys is a big mistake, Gargenta said, because anyone can create an update.zip firmware update file to replace any part of the system they want.

Users

Android doesn't use Linux users (and UIDs) in the usual way. There are "virtual users" that correspond to each app. When installed, an app gets a UID (and identical group ID) assigned to it. Up until Ice Cream Sandwich (ICS, Android 4.0), the UIDs were assigned starting at 10,001 and given names like app_N, where N is the offset from 10,000. After ICS, the mapping took multiple human users into account, so the names became uM_aN, where M corresponds to the human user, and uses a different formula (100,000 * user + appnum, so u10_a3 becomes 101,003 1,010,003).

There is no passwd file on an Android system, but the mapping from app to UID can be found in the /system/packages.list file. That file lists the app name, UID, and the location of the app's private data storage in the filesystem. When an app is first downloaded, it is put into a quarantine space and examined by installd; if the signature check passes, a UID/GID is assigned and the app is installed. It is possible to have multiple apps (all signed with the same key) running under the same UID, but they are really considered by the system to be part of the same app.

Files

Android has a few separate filesystems. The /system filesystem is "essentially the ROM", Gargenta said. It is mounted read-only and contains the Android OS, system libraries and apps, system executables, and so on. The application developer and user have no access to that filesystem (unless the device is rooted), and it contains no user data, so it doesn't need to be backed up or encrypted.

The /data partition is mounted read-write and contains all of the downloaded apps and the storage for all apps (including the system apps). The /data/data directory is the location where apps store their data. A a subdirectory named after the app is created that is owned by its UID/GID and has permissions that does not allow access from other UIDs. This is how the storage sandbox is handled. There is a lib directory in the app's storage, which holds the native libraries that the app needs. That directory is added to the LD_LIBRARY_PATH of apps before they are started.

The init process mounts the filesystems and sets the permissions for the files in those filesystems, which can be seen in the init.rc file. It ensures that /system is mounted read-only as it may have previously been mounted read-write for an over-the-air (OTA) update.

In Android 4.2 ("Jelly Bean"), support for multiple human users was added for uses like tablets that are shared by multiple family members. The number of supported users is set in a configuration file; for phones the value is 1, but tablets it is often set to 8. When there are multiple users, apps can be installed for one or more of them. In that case, the data is not shared—instead, each user gets their own copy of the app's data directory, but the code and libraries are shared (the latter using a symbolic link from the lib directory).

Permissions

Permissions are at the heart of the app security model for Android. One can see the list of all permissions in the system using the "pm list permissions" command in the adb shell. Also, the "run-as" command can be used to test permissions as granted to specific apps. That is useful for debugging and testing, Gargenta said.

Some permissions are better than others, at least in terms of being featured in the Google Play store, he said. He listed the Top Ten Bad Permissions. These are permissions that, if requested by an app, make it less likely to be featured in the store. For the most part, these are somewhat dangerous permissions that are a red flag that the application is asking for more than it needs—or more than it should need.

For example, the SEND_SMS and RECEIVE_SMS permissions (for sending and receiving text messages) were at the top of the list. Unless the app is an SMS program, it shouldn't be using those. Instead, it should start an SMS composer activity, which will activate an existing SMS app to handle the message. Similarly, using an intent for ACTION_IMAGE_CAPTURE will bring up the camera to allow the user to take a picture and return the result. That avoids requiring the CAMERA permission. He had suggestions for several other permissions as well.

Permissions in Android map to groups (i.e. GIDs). If a particular app is granted a permission, it is added to the group. For example, Android's "paranoid networking" works by checking if the user is in the "inet" group; if so, it allows network access, otherwise not. The permissions for files and devices are set by the init process

Gargenta also briefly looked at some other Android security topics, including encryption, malware, and device administration for companies that are issuing phones to their employees (or allowing those employees to use their own). Those topics were something of an aside to the deep dive into Android security. Overall, there was a lot to digest in a fairly short period of time, as Gargenta's slides would suggest. A longer time slot might have been harder to allocate for a two-day conference like ABS, but there was certainly material enough to fill it.

[ Thanks to the Linux Foundation for assisting with travel costs to San Francisco for ABS. ]

Comments (6 posted)

Brief items

Security quotes of the week

-- Matthew Garrett on third-party keys in a secure boot world

-- Bruce Schneier considers the possibility of hacking the election of a new pope

-- Adi Shamir, the "S" in RSA

Comments (9 posted)

A nasty local kernel vulnerability

Over the weekend, the networking tree accepted a fix for an out-of-bounds access error that appears to be exploitable by an unprivileged local user to gain root access. Even worse, there are indications that this bug (which affects kernels from 3.3 onward) has been known about since mid-2012; exploits exist in the wild. No distributor updates exist as of this writing; presumably they will not be long in coming.

[Update February 27: Distributions have started putting out updates for the vulnerability.]

Comments (68 posted)

New vulnerabilities

apache: cross-site scripting

Package(s):	apache	CVE #(s):	CVE-2012-3499 CVE-2012-4558
Created:	February 26, 2013	Updated:	April 5, 2013
Description:	From the Mandriva advisory: Various XSS (cross-site scripting vulnerability) flaws due to unescaped hostnames and URIs HTML output in mod_info, mod_status, mod_imagemap, mod_ldap, and mod_proxy_ftp (CVE-2012-3499). XSS (cross-site scripting vulnerability) in mod_proxy_balancer manager interface (CVE-2012-4558).
Alerts:	Mandriva MDVSA-2013:015 2013-02-26 Mageia MGASA-2013-0073 2013-02-27 Slackware SSA:2013-062-01 2013-03-03 Debian DSA-2637-1 2013-03-04 Ubuntu USN-1765-1 2013-03-18 Fedora FEDORA-2013-4541 2013-04-01 Mandriva MDVSA-2013:015-1 2013-04-04 openSUSE openSUSE-SU-2013:0629-1 2013-04-05 openSUSE openSUSE-SU-2013:0632-1 2013-04-05

Comments (none posted)

bind: denial of service

Package(s):	bind	CVE #(s):	CVE-2012-5689
Created:	February 22, 2013	Updated:	March 11, 2013
Description:	From the CVE entry: ISC BIND 9.8.x through 9.8.4-P1 and 9.9.x through 9.9.2-P1, in certain configurations involving DNS64 with a Response Policy Zone that lacks an AAAA rewrite rule, allows remote attackers to cause a denial of service (assertion failure and named daemon exit) via a query for an AAAA record.
Alerts:	Red Hat RHSA-2013:0550-01 2013-02-21 Oracle ELSA-2013-0550 2013-02-28 Scientific Linux SL-bind-20130228 2013-02-28 CentOS CESA-2013:0550 2013-03-09 Mageia MGASA-2013-0105 2013-04-04

Comments (none posted)

django: multiple vulnerabilities

Package(s):	python-django	CVE #(s):	CVE-2013-0305 CVE-2013-0306
Created:	February 27, 2013	Updated:	March 22, 2013
Description:	From the Debian advisory: CVE-2013-0305: Orange Tsai discovered that the bundled administrative interface of django could expose supposedly-hidden information via its history log. CVE-2013-0306: Mozilla discovered that an attacker can abuse django's tracking of the number of forms in a formset to cause a denial-of-service attack due to extreme memory consumption.
Alerts:	Debian DSA-2634-1 2013-02-27 Mageia MGASA-2013-0076 2013-03-01 Ubuntu USN-1757-1 2013-03-07 Fedora FEDORA-2013-2843 2013-03-12 Fedora FEDORA-2013-2874 2013-03-12 Red Hat RHSA-2013:0670-01 2013-03-21

Comments (none posted)

dovecot: restriction bypass/directory traversal

Package(s):	dovecot	CVE #(s):	CVE-2011-2166 CVE-2011-2167
Created:	February 21, 2013	Updated:	February 27, 2013
Description:	From the CVE entries: script-login in Dovecot 2.0.x before 2.0.13 does not follow the user and group configuration settings, which might allow remote authenticated users to bypass intended access restrictions by leveraging a script. (CVE-2011-2166) script-login in Dovecot 2.0.x before 2.0.13 does not follow the chroot configuration setting, which might allow remote authenticated users to conduct directory traversal attacks by leveraging a script. (CVE-2011-2167)
Alerts:	Red Hat RHSA-2013:0520-02 2013-02-21 Oracle ELSA-2013-0520 2013-02-25 Scientific Linux SL-dove-20130304 2013-03-04 CentOS CESA-2013:0520 2013-03-09

Comments (none posted)

evolution: information disclosure

Package(s):	evolution	CVE #(s):	CVE-2011-3201
Created:	February 21, 2013	Updated:	March 11, 2013
Description:	From the Red Hat advisory: The way Evolution handled mailto URLs allowed any file to be attached to the new message. This could lead to information disclosure if the user did not notice the attached file before sending the message. With this update, mailto URLs cannot be used to attach certain files, such as hidden files or files in hidden directories, files in the /etc/ directory, or files specified using a path containing "..".
Alerts:	Red Hat RHSA-2013:0516-02 2013-02-21 Oracle ELSA-2013-0516 2013-02-25 Scientific Linux SL-evol-20130304 2013-03-04 CentOS CESA-2013:0516 2013-03-09

Comments (none posted)

fusionforge: multiple privilege escalation flaws

Package(s):	fusionforge	CVE #(s):	CVE-2013-1423
Created:	February 27, 2013	Updated:	February 27, 2013
Description:	From the Debian advisory: Helmut Grohne discovered multiple privilege escalation flaws in FusionForge, a web-based project-management and collaboration software. Most of the vulnerabilities are related to the bad handling of privileged operations on user-controlled files or directories.
Alerts:	Debian DSA-2633-1 2013-02-26

Comments (none posted)

hplip: insecure temp files

Package(s):	hplip	CVE #(s):	CVE-2013-0200
Created:	February 21, 2013	Updated:	February 28, 2013
Description:	From the Red Hat advisory: Tim Waugh of Red Hat discovered temporary file handling flaws in HPLIP. A local attacker could use these flaws to perform a symbolic link attack, overwriting arbitrary files accessible to a process using HPLIP.
Alerts:	Red Hat RHSA-2013:0500-02 2013-02-21 Mageia MGASA-2013-0072 2013-02-27 Oracle ELSA-2013-0500 2013-02-28 Scientific Linux SL-hpli-20130304 2013-03-04 CentOS CESA-2013:0500 2013-03-09

Comments (none posted)

java: unspecified vulnerability

Package(s):	java	CVE #(s):	CVE-2013-1487
Created:	February 21, 2013	Updated:	February 27, 2013
Description:	From the CVE entry: Unspecified vulnerability in the Java Runtime Environment component in Oracle Java SE 7 Update 13 and earlier and 6 Update 39 and earlier allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Deployment.
Alerts:	Red Hat RHSA-2013:0531-01 2013-02-20 Red Hat RHSA-2013:0532-01 2013-02-20 Ubuntu USN-1735-1 2013-02-21 Mandriva MDVSA-2013:014 2013-02-22 Scientific Linux SL-java-20130227 2013-02-27 Red Hat RHSA-2013:0625-01 2013-03-11 Red Hat RHSA-2013:0626-01 2013-03-11 SUSE SUSE-SU-2013:0440-1 2013-03-13 SUSE SUSE-SU-2013:0456-2 2013-03-14 SUSE SUSE-SU-2013:0456-1 2013-03-14 SUSE SUSE-SU-2013:0456-3 2013-03-15 SUSE SUSE-SU-2013:0456-4 2013-03-15

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2012-4542 CVE-2013-0309 CVE-2013-0310 CVE-2013-0311
Created:	February 21, 2013	Updated:	March 15, 2013
Description:	From the Red Hat advisory: It was found that the default SCSI command filter does not accommodate commands that overlap across device classes. A privileged guest user could potentially use this flaw to write arbitrary data to a LUN that is passed-through as read-only. (CVE-2012-4542) A flaw was found in the way pmd_present() interacted with PROT_NONE memory ranges when transparent hugepages were in use. A local, unprivileged user could use this flaw to crash the system. (CVE-2013-0309) A flaw was found in the way CIPSO (Common IP Security Option) IP options were validated when set from user mode. A local user able to set CIPSO IP options on the socket could use this flaw to crash the system. (CVE-2013-0310) A flaw was found in the way the vhost kernel module handled descriptors that spanned multiple regions. A privileged guest user in a KVM guest could use this flaw to crash the host or, potentially, escalate their privileges on the host. (CVE-2013-0311)
Alerts:	Red Hat RHSA-2013:0496-02 2013-02-21 Oracle ELSA-2013-0496 2013-02-28 Oracle ELSA-2013-2507 2013-02-28 openSUSE openSUSE-SU-2013:0396-1 2013-03-05 Ubuntu USN-1756-1 2013-03-06 CentOS CESA-2013:0496 2013-03-09 Red Hat RHSA-2013:0622-01 2013-03-11 Ubuntu USN-1760-1 2013-03-12 Scientific Linux SL-kern-20130314 2013-03-14 Ubuntu USN-1767-1 2013-03-18 Ubuntu USN-1769-1 2013-03-18 Ubuntu USN-1768-1 2013-03-18 Ubuntu USN-1774-1 2013-03-21 Ubuntu USN-1775-1 2013-03-22 Ubuntu USN-1776-1 2013-03-22 Ubuntu USN-1778-1 2013-03-22 Ubuntu USN-1781-1 2013-03-26

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):	kernel	CVE #(s):	CVE-2013-0228 CVE-2013-0313 CVE-2013-0871
Created:	February 22, 2013	Updated:	April 3, 2013
Description:	From the Mageia advisory: Linux kernel when returning from an iret assumes that %ds segment is safe and uses it to reference various per-cpu related fields. Unfortunately the user can modify the LDT and provide a NULL one. Whenever an iret is called we end up in xen_iret and try to use the %ds segment and cause an general protection fault. Malicious or buggy unprivileged user space can cause the guest kernel to crash, or permit a privilege escalation within the guest, or operate erroneously. (CVE-2013-0228) Linux kernel built with Extended Verification Module(EVM) and configured properly, is vulnerable to a NULL pointer de-reference flaw, caused by accessing extended attribute routines of sockfs inode object. An unprivileged user/program could use this to crash the kernel, resulting in DoS. (CVE-2013-0313) A race condition in ptrace can lead to kernel stack corruption and arbitrary kernel-mode code execution. (CVE-2013-0871)
Alerts:	Mageia MGASA-2013-0066 2013-02-22 Mageia MGASA-2013-0067 2013-02-22 Mageia MGASA-2013-0068 2013-02-22 Mageia MGASA-2013-0069 2013-02-22 Mageia MGASA-2013-0070 2013-02-22 Ubuntu USN-1736-1 2013-02-21 Ubuntu USN-1739-1 2013-02-21 Ubuntu USN-1741-1 2013-02-21 Ubuntu USN-1744-1 2013-02-21 Ubuntu USN-1740-1 2013-02-21 Ubuntu USN-1742-1 2013-02-21 Ubuntu USN-1745-1 2013-02-21 Ubuntu USN-1737-1 2013-02-21 Ubuntu USN-1738-1 2013-02-21 Ubuntu USN-1743-1 2013-02-21 Fedora FEDORA-2013-2597 2013-02-24 SUSE SUSE-SU-2013:0341-1 2013-02-25 Debian DSA-2632-1 2013-02-25 Red Hat RHSA-2013:0567-01 2013-02-26 Oracle ELSA-2013-2507 2013-02-28 Oracle ELSA-2013-0567 2013-02-28 openSUSE openSUSE-SU-2013:0396-1 2013-03-05 Ubuntu USN-1756-1 2013-03-06 CentOS CESA-2013:0567 2013-03-09 Red Hat RHSA-2013:0621-01 2013-03-11 Red Hat RHSA-2013:0622-01 2013-03-11 CentOS CESA-2013:0621 2013-03-12 Scientific Linux SL-kern-20130312 2013-03-12 Red Hat RHSA-2013:0630-01 2013-03-12 CentOS CESA-2013:0630 2013-03-13 Oracle ELSA-2013-0621 2013-03-12 Oracle ELSA-2013-0630 2013-03-12 Ubuntu USN-1760-1 2013-03-12 Scientific Linux SL-kern-20130314 2013-03-14 Scientific Linux SL-kern-20130314 2013-03-14 Ubuntu USN-1767-1 2013-03-18 Ubuntu USN-1769-1 2013-03-18 Ubuntu USN-1768-1 2013-03-18 Red Hat RHSA-2013:0661-01 2013-03-19 Red Hat RHSA-2013:0662-01 2013-03-19 Fedora FEDORA-2013-3909 2013-03-22 Ubuntu USN-1778-1 2013-03-22 Scientific Linux SL-kern-20130325 2013-03-25 Ubuntu USN-1781-1 2013-03-26 Red Hat RHSA-2013:0695-01 2013-04-02

Comments (none posted)

kernel: privilege escalation

Package(s):	kernel	CVE #(s):	CVE-2013-1763
Created:	February 26, 2013	Updated:	March 22, 2013
Description:	Mathias Krause discovered a bounds checking error for netlink messages requesting SOCK_DIAG_BY_FAMILY. An unprivileged local user could exploit this flaw to crash the system or run programs as an administrator. This patch fixes the problem.
Alerts:	Ubuntu USN-1749-1 2013-02-26 Fedora FEDORA-2013-3086 2013-02-27 Ubuntu USN-1750-1 2013-02-26 Ubuntu USN-1751-1 2013-02-26 Mageia MGASA-2013-0079 2013-03-02 Mageia MGASA-2013-0080 2013-03-02 Mageia MGASA-2013-0081 2013-03-02 Mageia MGASA-2013-0082 2013-03-02 Mageia MGASA-2013-0083 2013-03-02 Fedora FEDORA-2013-3223 2013-03-02 Fedora FEDORA-2013-3106 2013-03-02 openSUSE openSUSE-SU-2013:0395-1 2013-03-05 Red Hat RHSA-2013:0622-01 2013-03-11 Fedora FEDORA-2013-3909 2013-03-22

Comments (none posted)

keystone: multiple vulnerabilities

Package(s):	keystone	CVE #(s):	CVE-2013-0282 CVE-2013-1664 CVE-2013-1665
Created:	February 21, 2013	Updated:	March 22, 2013
Description:	From the Ubuntu advisory: Nathanael Burton discovered that Keystone did not properly verify disabled users. An authenticated but disabled user would continue to have access rights that were removed. (CVE-2013-0282) Jonathan Murray discovered that Keystone would allow XML entity processing. A remote unauthenticated attacker could exploit this to cause a denial of service via resource exhaustion. Authenticated users could also use this to view arbitrary files on the Keystone server. (CVE-2013-1664, CVE-2013-1665)
Alerts:	Ubuntu USN-1730-1 2013-02-20 Ubuntu USN-1731-1 2013-02-20 Ubuntu USN-1734-1 2013-02-21 Debian DSA-2634-1 2013-02-27 Fedora FEDORA-2013-2916 2013-03-04 Red Hat RHSA-2013:0596-01 2013-03-05 Ubuntu USN-1757-1 2013-03-07 Red Hat RHSA-2013:0670-01 2013-03-21 Red Hat RHSA-2013:0658-01 2013-03-21 Red Hat RHSA-2013:0657-01 2013-03-21

Comments (none posted)

mozilla: distinguishing and plaintext-recovery attacks

Package(s):	firefox thunderbird nss	CVE #(s):	CVE-2013-1620
Created:	February 22, 2013	Updated:	April 5, 2013
Description:	From the CVE entry: The TLS implementation in Mozilla Network Security Services (NSS) does not properly consider timing side-channel attacks on a noncompliant MAC check operation during the processing of malformed CBC padding, which allows remote attackers to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data for crafted packets, a related issue to CVE-2013-0169.
Alerts:	Mageia MGASA-2013-0063 2013-02-21 Fedora FEDORA-2013-2929 2013-02-28 Fedora FEDORA-2013-2929 2013-02-28 Fedora FEDORA-2013-2929 2013-02-28 Fedora FEDORA-2013-2929 2013-02-28 Fedora FEDORA-2013-3079 2013-03-14 Fedora FEDORA-2013-3079 2013-03-14 Fedora FEDORA-2013-3079 2013-03-14 Fedora FEDORA-2013-3079 2013-03-14 Ubuntu USN-1763-1 2013-03-14 Ubuntu USN-1763-2 2013-03-14 openSUSE openSUSE-SU-2013:0630-1 2013-04-05 Fedora FEDORA-2013-4832 2013-04-05 Fedora FEDORA-2013-4832 2013-04-05 openSUSE openSUSE-SU-2013:0631-1 2013-04-05 Mandriva MDVSA-2013:050 2013-04-05

Comments (none posted)

openssh: code execution

Package(s):	openssh	CVE #(s):	CVE-2012-5536
Created:	February 21, 2013	Updated:	March 11, 2013
Description:	From the Red Hat advisory: Due to the way the pam_ssh_agent_auth PAM module was built in Red Hat Enterprise Linux 6, the glibc's error() function was called rather than the intended error() function in pam_ssh_agent_auth to report errors. As these two functions expect different arguments, it was possible for an attacker to cause an application using pam_ssh_agent_auth to crash, disclose portions of its memory or, potentially, execute arbitrary code.
Alerts:	Red Hat RHSA-2013:0519-02 2013-02-21 Oracle ELSA-2013-0519 2013-02-25 Scientific Linux SL-open-20130228 2013-02-28 CentOS CESA-2013:0519 2013-03-09

Comments (none posted)

openssl: denial of service

Package(s):	openssl	CVE #(s):	CVE-2012-2686
Created:	February 21, 2013	Updated:	February 27, 2013
Description:	From the Ubuntu advisory: Adam Langley and Wolfgang Ettlingers discovered that OpenSSL incorrectly handled certain crafted CBC data when used with AES-NI. A remote attacker could use this issue to cause OpenSSL to crash, resulting in a denial of service.
Alerts:	Ubuntu USN-1732-1 2013-02-21 openSUSE openSUSE-SU-2013:0337-1 2013-02-25 openSUSE openSUSE-SU-2013:0336-1 2013-02-25 openSUSE openSUSE-SU-2013:0339-1 2013-02-25 Ubuntu USN-1732-2 2013-02-28 Ubuntu USN-1732-3 2013-03-25

Comments (none posted)

pigz: information disclosure

Package(s):	pigz	CVE #(s):	CVE-2013-0296
Created:	February 26, 2013	Updated:	March 27, 2013
Description:	From the Red Hat bugzilla: A security flaw was found in the way pigz, a parallel implementation of gzip, created temporary files to (temporary) store / represent 'to be compressed archive content' (the files were created with world readable permissions). A local attacker could use this flaw to obtain sensitive information (archive content).
Alerts:	Fedora FEDORA-2013-2589 2013-02-26 openSUSE openSUSE-SU-2013:0540-1 2013-03-26

Comments (none posted)

pixman: stack-based buffer overflow

Package(s):	pixman	CVE #(s):	CVE-2013-1591
Created:	February 27, 2013	Updated:	March 28, 2013
Description:	From the Red Hat bugzilla: Stack-based buffer overflow in libpixman, as used in Pale Moon before 15.4, has unspecified impact and attack vectors. The upstream commit to correct this flaw: http://cgit.freedesktop.org/pixman/commit... The affected code (pixman/pixman-inlines.h, fast_composite_scaled_bilinear()) is present in the version of pixmap shipped with Fedora 17 (0.24.4), but is not present in Red Hat Enterprise Linux 5 or 6 (the fast_composite_scaled_bilinear() function is in pixman/pixman-fast-path.h, but the vulnerable code is not there and I don't detect anything comparable). So it's likely that the vulnerable code was introduced after 0.22.0.
Alerts:	Fedora FEDORA-2013-2414 2013-02-27 Mageia MGASA-2013-0077 2013-03-01 Fedora FEDORA-2013-2450 2013-03-02 Red Hat RHSA-2013:0687-01 2013-03-27 CentOS CESA-2013:0687 2013-03-27 Oracle ELSA-2013-0687 2013-03-27 Scientific Linux SL-pixm-20130327 2013-03-27

Comments (none posted)

rails: multiple vulnerabilities

Package(s):	RubyOnRails	CVE #(s):	CVE-2013-0262 CVE-2013-0263
Created:	February 25, 2013	Updated:	March 15, 2013
Description:	From the CVE entries: rack/file.rb (Rack::File) in Rack 1.5.x before 1.5.2 and 1.4.x before 1.4.5 allows attackers to access arbitrary files outside the intended root directory via a crafted PATH_INFO environment variable, probably a directory traversal vulnerability that is remotely exploitable, aka "symlink path traversals." (CVE-2013-0262) Rack::Session::Cookie in Rack 1.5.x before 1.5.2, 1.4.x before 1.4.5, 1.3.x before 1.3.10, 1.2.x before 1.2.8, and 1.1.x before 1.1.6 allows remote attackers to guess the session cookie, gain privileges, and execute arbitrary code via a timing attack involving am HMAC comparison function that does not run in constant time. (CVE-2013-0263)
Alerts:	openSUSE openSUSE-SU-2013:0338-1 2013-02-25 Red Hat RHSA-2013:0638-01 2013-03-12 openSUSE openSUSE-SU-2013:0462-1 2013-03-14

Comments (none posted)

rdma: multiple vulnerabilities

Package(s):	RDMA	CVE #(s):	CVE-2012-4517 CVE-2012-4518
Created:	February 21, 2013	Updated:	March 11, 2013
Description:	From the Red Hat advisory: A denial of service flaw was found in the way ibacm managed reference counts for multicast connections. An attacker could send specially-crafted multicast packets that would cause the ibacm daemon to crash. (CVE-2012-4517) It was found that the ibacm daemon created some files with world-writable permissions. A local attacker could use this flaw to overwrite the contents of the ibacm.log or ibacm.port file, allowing them to mask certain actions from the log or cause ibacm to run on a non-default port. (CVE-2012-4518)
Alerts:	Red Hat RHSA-2013:0509-02 2013-02-21 Oracle ELSA-2013-0509 2013-02-25 Scientific Linux SL-rdma-20130304 2013-03-04 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09 CentOS CESA-2013:0509 2013-03-09

Comments (none posted)

ruby: denial of service

Package(s):	ruby1.9.1	CVE #(s):	CVE-2013-0269
Created:	February 21, 2013	Updated:	April 4, 2013
Description:	From the CVE entry: The JSON gem 1.7.x before 1.7.7, 1.6.x before 1.6.8, and 1.5.x before 1.5.5 allows remote attackers to cause a denial of service (resource consumption) or bypass the mass assignment protection mechanism via a crafted JSON document that triggers the creation of arbitrary Ruby symbols or certain internal objects, as demonstrated by conducting a SQL injection attack against Ruby on Rails, aka "Unsafe Object Creation Vulnerability."
Alerts:	Ubuntu USN-1733-1 2013-02-21 Fedora FEDORA-2013-3052 2013-03-05 Fedora FEDORA-2013-3050 2013-03-05 Slackware SSA:2013-075-01 2013-03-16 Red Hat RHSA-2013:0701-01 2013-04-02 openSUSE openSUSE-SU-2013:0603-1 2013-04-03 SUSE SUSE-SU-2013:0609-1 2013-04-03 SUSE SUSE-SU-2013:0612-1 2013-04-03 SUSE SUSE-SU-2013:0615-1 2013-04-03

Comments (none posted)

transmission: code execution

Package(s):	transmission	CVE #(s):	CVE-2012-6129
Created:	February 25, 2013	Updated:	March 20, 2013
Description:	From the Ubuntu advisory: It was discovered that Transmission incorrectly handled certain micro transport protocol packets. A remote attacker could use this issue to cause a denial of service, or possibly execute arbitrary code.
Alerts:	Ubuntu USN-1747-1 2013-02-25 Mageia MGASA-2013-0074 2013-02-27 openSUSE openSUSE-SU-2013:0485-1 2013-03-19

Comments (none posted)

util-linux-ng: information disclosure

Package(s):	util-linux-ng	CVE #(s):	CVE-2013-0157
Created:	February 21, 2013	Updated:	March 11, 2013
Description:	From the Red Hat advisory: An information disclosure flaw was found in the way the mount command reported errors. A local attacker could use this flaw to determine the existence of files and directories they do not have access to.
Alerts:	Red Hat RHSA-2013:0517-02 2013-02-21 Oracle ELSA-2013-0517 2013-02-25 Scientific Linux SL-util-20130304 2013-03-04 CentOS CESA-2013:0517 2013-03-09

Comments (none posted)

Page editor: Jake Edge

Kernel development

Brief items

Kernel release status

The 3.9 merge window is open so there is no current development kernel. See the separate article below for a summary of changes merged into the mainline for 3.9 so far.

Stable updates: 3.4.33 and 3.0.66 were released on February 21; they are single-patch updates fixing a security issue in the printk() code. 3.5.7.6 was released on February 22, and 3.7.10 (the final planned 3.7 update) was released on February 27.

As of this writing, the 3.8.1, 3.4.34, and 3.0.67 updates are in the review process; they can be expected on or after February 28.

Comments (2 posted)

Quotes of the week

— Jason A. Donenfeld

— Kurt Seifried

— Ingo Molnar

Comments (19 posted)

Kernel development news

3.9 Merge window, second episode

As of this writing, just over 8,000 non-merge changesets have been pulled into the mainline for the 3.9 development cycle — 7,600 since last week's summary. Quite a few new features of interest have been merged for the 3.9 kernel; the most significant of those are listed below.

But first, a warning for development kernel testers: there are reports of ext4 filesystem corruption with current mainline kernels. The problem appears to have been identified and fixed, but it will remain as a permanent hazard for anybody running bisections over the 3.9 merge window. Development kernels have not often lived up to their fearsome reputation recently, but they can still bite at times.

• The ARM architecture has gained support for the KVM virtualization mechanism on Cortex-A15 processors. Support for the ARM "power state coordination interface" has been added so that virtual CPU's can be "powered up" and down.

• The socket filtering mechanism has a new SO_LOCK_FILTER option that prevents further changes to the filter. It is intended for privileged programs that install a filter before running untrusted code.

• TCP and UDP sockets have a new option, SO_REUSEPORT, that allows multiple sockets listening for new connections or packets (respectively) at the same time. See this commit message for more information.

• The netfilter connection-tracking code now supports "connection labels," which are bitmasks that can be attached to tracking entries and tested by netfilter rules.

• The wireless networking subsystem has gained core support for the detection of radar systems operating on the networking frequencies; this is a necessary component for dynamic frequency selection in the 5GHz range.

• VMware's "VM Sockets" subsystem, a mechanism for communication between virtual machines and a hypervisor, has been merged. Also merged is the "Virtual Machine Communication Interface" subsystem for high-speed communication between the host and guests.

• The networking layer has support for the "Multiple VLAN Registration Protocol" (MVRP), which facilitates communication about registered virtual networks to switches.

• The block layer's handling of pages under writeback has been changed to address the performance penalty imposed by the previous "stable pages" work.

• The PowerPC architecture supports a new set of transactional memory instructions; at this time, only user-space support is provided (the kernel does not use these instructions). See Documentation/powerpc/transactional_memory.txt for more information.

• The Xen virtualization subsystem gained support for ACPI-based CPU and memory hotplugging, though, in both cases, only the "add" operation is supported currently.

• The ext4 filesystem now supports hole punching in block-mapped files.

• A long list of old network drivers has been deleted; these include the venerable 3c501, 3c505, and 3c507 drivers, various Intel i825xx drivers, parallel port-based drivers(!), and many more. It is expected that these drivers will not be missed, as many of them did not work all that well in the first place. As Paul Gortmaker put it: "You know things are not good when the Kconfig help text suggests you make a cron job doing a ping every minute." The long-unused "WAN router" subsystem has also been removed.

• New hardware support includes:
  • Systems and processors: NVIDIA Tegra114 SoCs, the ARM "dummy virtual machine" (a minimal stub platform for virtualization uses), Prodrive PPA8548 AMC modules, and Tensilica Diamond 233L Standard core Rev.C processors.

  • Audio: NVIDIA Tegra20 AC97 interfaces.

  • Block: Renesas R-Car SATA controllers and Broadcom BCM2835 SD/MMC controllers.

  • Graphics: Marvell MMP display controllers, Samsung LMS501KF03 LCD panels, Himax HX-8357 LCD panels, Austrian Microsystems AS3711 backlight controllers, TI LCDC display controllers, and NXP Semiconductors TDA998X HDMI encoders.

  • Input: Steelseries SRW-S1 steering wheel devices.

  • Miscellaneous: STMicroelectronics ST33 I2C TPM devices, STMicroelectronics accelerometers, magnetometers, and gyroscopes, InvenSense ITG3200 digital 3-axis gyroscopes, Invensense MPU6050 gyroscope/accelerometer devices, NVIDIA Tegra20/30 SoC serial controllers, Comtrol RocketPort EXPRESS/INFINITY serial adapters, PCI-Express non-transparent bridges, Maxim MAX77686 and MAX8997 realtime clocks (RTCs), TI LP8788 RTCs, TI TPS80031/TPS80032 RTCs, Epson RX-4581 RTCs, ST-Ericsson Ux500 watchdogs, Intel Lynxpoint GPIO controllers, Atmel Timer Counter pulse-width modulators, TI/National LP5521 and LP5523/55231 LED controllers, Intel iSMT SMBus host controllers, and Broadcom BCM2835 I2C controllers.

  • Networking: 8devices USB2CAN interfaces and Inside Secure microread NFC interfaces.

  • USB: SMSC USB3503 USB 2.0 hub controllers.

  • Video4Linux: SuperH VEU mem2mem video processors, TI DM365 VPFE media controllers, Montage Technology TS2020-based tuners, Masterkit MA901 USB FM radios, OmniVision OV9650/OV9652 sensors, and Samsung S5C73M3 sensors.

  • Staging graduations: the Analog Devices ADXRS450/3 Digital Output Gyroscope SPI driver, Analog Devices ADIS16400 inertial sensor driver, Analog Devices ADIS16080/100 yaw rate gyroscope driver, Kionix KXSD9 accelerometer driver, TAOS TSL2560, TSL2561, TSL2562 and TSL2563 ambient light sensor driver, and OMAP direct rendering driver have been moved out of the staging tree and into the mainline kernel.

Changes visible to kernel developers include:

• The netpoll mechanism now supports IPv6, allowing network consoles to be run over IPv6 networks.

• Most drivers no longer depend on the EXPERIMENTAL configuration option. So much code needed that option that it is turned on almost universally, with the result that it does not actually mean anything. So now it defaults to "yes," and it will soon be removed entirely.

• The sound layer has a generic parser for Intel high definition audio (HDA) codecs. Many drivers have been converted to use this parser, resulting in the removal of a great deal of duplicated code.

• The __get_user_8() function is now available on 32-bit x86 systems; it will fetch a 64-bit quantity from user space.

• The module signing code has a few usability enhancements. The sign-file utility has new options to specify which hash algorithm to use or to simply provide the entire signature (which will have been computed elsewhere). There is also a new MODULE_SIG_ALL configuration option that controls whether modules are automatically signed at modules_install time.

• The descriptor-based GPIO patch set has been merged, with significant changes to how GPIO lines are handled within the kernel.

• The new file_inode() helper should be used instead of the traditional file->f_dentry->d_inode pointer chain.

The merge window should stay open through approximately March 5, though, one assumes, the rate of change will drop off somewhat toward the end. Next week's edition will summarize the changes that go in for the final part of the 3.9 merge window.

Comments (7 posted)

ELC: In-kernel switcher for big.LITTLE

The ARM big.LITTLE architecture has been the subject of a number of LWN articles (here's another) and conference talks, as well as a fair amount of code. A number of upcoming systems-on-chip (SoCs) will be using the architecture, so some kind of near-term solution for Linux support is needed. Linaro's Mathieu Poirier came to the 2013 Embedded Linux Conference to describe that interim solution: the in-kernel switcher.

Two kinds of CPUs

Big.LITTLE incorporates architecturally similar CPUs that have different power and performance characteristics. The similarity must consist of a one-to-one mapping between instruction sets on the two CPUs, so that code can "migrate seamlessly", Poirier said. Identical CPUs are grouped into clusters.

The SoC he has been using for testing consists of three Cortex-A7 CPUs (LITTLE: less performance, less power consumption) in one cluster and two Cortex-A15s (big) in the other. The SoC was deliberately chosen to have a different number of processors in the clusters as a kind of worst case to catch any problems that might arise from the asymmetry. Normally, one would want the same number of processors in each cluster, he said.

The clusters are connected with a cache-coherent interconnect, which can snoop the cache to keep it coherent between clusters. There is an interrupt controller on the SoC that can route any interrupt from or to any CPU. In addition, there is support in the SoC for I/O coherency that can be used to keep GPUs or other external processors cache-coherent, but that isn't needed for Linaro's tests.

The idea behind big.LITTLE is to provide a balance between power consumption and performance. The first idea was to run CPU-hungry tasks on the A15s, and less hungry tasks on the A7s. Unfortunately, it is "hard to predict the future", Poirier said, which made it difficult to make the right decisions because there is no way to know what tasks are CPU intensive ahead of time.

Two big.LITTLE approaches

That led Linaro to a two-pronged approach to solving the problem: Heterogeneous Multi-Processing (HMP) and the In-Kernel Switcher (IKS). The two projects are running in parallel and are both in the same kernel tree. Not only that, but you can enable either on the kernel command line or switch at run time via sysfs.

With HMP, all of the cores in the SoC can be used at the same time, but the scheduler needs to be aware of the capabilities of the different processors to make its decisions. It will lead to higher peak performance for some workloads, Poirier said. HMP is being developed in the open, and anyone can participate, which means it will take somewhat longer before it is ready, he said.

IKS is meant to provide a "solution for now", he said, one that can be used to build products with. The basic idea is that one A7 and one A15 are coupled into a single virtual CPU. Each virtual CPU in the system will then have the same capabilities, thus isolating the core kernel from the asymmetry of big.LITTLE. That means much less code needs to change.

Only one of the two processors in a virtual CPU is active at any given time, so the decision on which of the two to use can be made at the CPU frequency (cpufreq) driver level. IKS was released to Linaro members in December 2012, and is "providing pretty good results", Poirier said.

An alternate way to group the processors would be to put all the A15s together and all the A7s into another group. That turned out to be too coarse as it was "all or nothing" in terms of power and performance. There was also a longer synchronization period needed when switching between those groups. Instead, it made more sense to integrate "vertically", pairing A7s with A15s.

For the test SoC, the "extra" A7 was powered off, leaving two virtual CPUs to use. The processors are numbered (A15_0, A15_1, A7_0, A7_1) and then paired up (i.e. {A15_0, A7_0}) into virtual CPUs; "it's not rocket science", Poirier said. One processor in each group is turned off, but only the cpufreq driver and the switching logic need to know that there are more physical processors than virtual processors.

The virtual CPU presents a list of operating frequencies that encompass the range of frequencies that both A7 and A15 can operate at. While the numbers look like frequencies (ranging from 175MHz to 1200MHz in the example he gave), they don't really need to be as they are essentially just indexes into a table in the cpufreq driver. The driver maps those values to a real operating point for one of the two processors.

Switching CPUs

The cpufreq core is not aware of the big.LITTLE architecture, so the driver does a good bit of work, Poirier said, but the code for making the switching decision is simple. If the requested frequency can't be supported by the current processor, switch to the other. That part is eight lines of code, he said.

For example, if virtual CPU 0 is running on the A7 at 200MHz and a request comes in to go to 1.2GHz, the driver recognizes that the A7 cannot support that. In that case, it decides to power down the A7 (which is called the outbound processor) and power up the A15 (inbound). There is a synchronization process that happens as part of the transition so that the inbound processor can use the existing cache. That process is described in Poirier's slides [PDF], starting at slide 17.

The outbound processor powers up the inbound and continues executing normal kernel/user-space code until it receives the "inbound alive" signal. After sending that signal, the inbound processor initializes both the cluster and interconnect if it is the first in its cluster (i.e. the other processor of the same type, in the other virtual CPU is powered down). It then waits for a signal from the outbound processor.

Once the outbound processor receives "inbound alive" signal, the blackout period (i.e. time when no kernel or user code is running on the virtual CPU) begins. The outbound processor disables interrupts, migrates the interrupt signals to the inbound processor, then saves the current CPU context. Once that's done, it signals the inbound processor, which restores the context, enables interrupts, and continues executing from where the outbound processor left off. All of that is possible because the instruction sets of the two processors are identical.

As part of its cleanup, the outbound processor creates a new stack for itself so that it won't interfere with the inbound. It then flushes the local cache and checks to see if it is the last one standing in its cluster; if so, it flushes the cluster cache and disables the cache-coherent interconnect. It then powers itself off.

There are some pieces missing from the picture that he painted, Poirier said, including "vlocks" and other mutual exclusion mechanisms to handle simultaneous desired cluster power states. Also missing was discussion of the "early poke" mechanism as well as code needed to track the CPU and cluster states.

Performance

One of Linaro's main targets is Android, so it used the interactive power governor for its testing. Any governor will work, he said, but will need to be tweaked. A second threshold (hispeed_freq2) was added to the interactive governor to delay going into "overdrive" on the A15 too quickly as those are "very power hungry" states.

For testing, BBench was used. It gives a performance score based on how fast web pages are loaded. That was run with audio playing in the background. The goal was to get 90% of the performance of two A15s, while using 60% of the power, which was achieved. Different governor parameters gave 95% performance with 65% of the power consumption.

It is important to note that tuning is definitely required—without it you can do worse than the performance of two A7s. "If you don't tune, all efforts are wasted", Poirier said. The interactive governor has 15-20 variables, but Linaro mainly concentrated on hispeed_load and hispeed_freq (and the corresponding *2 parameters added for handling overdrive). The basic configuration had the virtual CPU run on the A7 until the load reached 85%, when it would switch to the first six (i.e. non-overdrive) frequencies on the A15. After 95% load, it would use the two overdrive frequencies.

The upstreaming process has started, with the cluster power management code getting "positive remarks" on the ARM Linux mailing list. The goal is to upstream the code entirely, though some parts of it are only available to Linaro members at the moment. The missing source will be made public once a member ships a product using IKS. But, IKS is "just a stepping stone", Poirier said, and "HMP will blow this out of the water". It may take a while before HMP is ready, though, so IKS will be available in the meantime.

[ I would like to thank the Linux Foundation for travel assistance to attend ELC. ]

Comments (1 posted)

Loading keys from Microsoft PE binaries

The kernel does not run programs in Microsoft's Portable Executable (PE) format. So when a patch came along adding support for those binaries — not to run programs, but to use them as a container for trusted keys — the reaction was not entirely positive. In truth, the reaction was sufficiently negative to be widely quoted across the net. When one looks beyond the foul language, though, there are some fundamental questions about how Linux should support the UEFI secure boot mechanism and how much the kernel community needs to be concerned about Microsoft's wishes in this area.

The work done at Red Hat, SUSE, the Linux Foundation, and elsewhere is sufficient to enable a distributor to ship a binary distribution that will boot on a secure-boot-enabled system. Such distributions are often built so that they will only load kernel modules that have been signed by a trusted key, normally the distributor's own key. That restriction naturally causes problems for companies that ship binary-only modules; such modules will not be loadable into a secure-boot system. Many developers in the kernel community are not overly concerned about this difficulty; many of them, being hostile to the idea of binary-only modules in the first place, think this situation is just fine. Distributors like Red Hat, though, are not so sanguine.

One solution, of course, would be for those distributors to just sign the relevant binary modules directly. As Matthew Garrett points out, though, there are a number of practical difficulties with this approach, including the surprisingly difficult task of verifying the identity and trustworthiness of the company shipping the module. There's also the little problem that signing binary-only modules might make Red Hat look bad in various parts of our community and give strength to those claiming that such modules have no GPL compliance problems. So Red Hat would like to find a way to enable proprietary modules to be loaded without touching them directly, allowing the company to pretend not to be involved in the whole thing.

Red Hat's solution is to convince the kernel to trust any signing key that has been signed by Microsoft. Binary module vendors could then go to Microsoft to get their own key signed and present it to the kernel as being trustworthy; the kernel would then agree to load modules signed with this key. This only works, of course, if the kernel already trusts Microsoft's key, but that will be the case for all of the secure boot solutions that exist thus far. There is one other little problem in that the only thing Microsoft will sign is a PE binary. So Red Hat's scheme requires that the vendor's key be packaged into a PE binary for Microsoft to sign. Then the kernel will read the binary file, verify Microsoft's signature, extract the new key, and add that key to the ring of keys it trusts. Once that is done, the kernel will happily load modules signed by the new key.

This solution seems almost certain not to find its way into the mainline kernel. In retrospect, it is unsurprising that a significant patch that is seen as simultaneously catering to the wishes of Microsoft and binary module vendors would run into a bit of resistance. That is even more true when there appear to be reasonable alternatives, such as either (1) having Red Hat sign the modules directly, or (2) having Red Hat sign the vendor keys with its own key. Such solutions are unpopular because, as mentioned above, they reduce Red Hat's plausible deniability; they also make revocation harder and almost certainly require vendors to get a separate signature for each distribution they wish to support.

Linus has made it clear that he is not worried about those problems, though. Security, he says, should be in the control of the users; it should not be a mechanism used to strengthen a big company's control. So, rather than wiring Microsoft's approval further into the kernel, he would rather that distributors encourage approaches that educate users, improve their control, and which, he says, would ultimately be more secure. Loading a module in this environment, he said, would be a matter of getting the user to verify that the module is wanted rather than verifying a signing key.

The other reason that this patch is running into resistance is that there is widespread skepticism of the claim that the loading of unsigned modules must be blocked in the first place. Proponents claim that module signing (along with a whole set of other restrictions) is needed to prevent Linux from being used as a way to circumvent the secure boot mechanism and run compromised versions of Windows. Microsoft, it is said, will happily blacklist the Linux bootloader if Linux systems are seen as being a threat to Windows systems. Rather than run that risk, Linux, while running under secure boot, must prevent the running of arbitrary kernel code in any way. That includes blocking the loading of unsigned kernel modules.

It seems that not all kernel developers are worried about this possibility. Greg Kroah-Hartman asserted that module signature verification is not mandated by UEFI. Ted Ts'o added that Microsoft would suffer public relations damage and find itself under antitrust scrutiny if it were to act to block Linux from booting. It also seems unlikely to some that an attacker could rig a system to boot Linux, load a corrupted module, then chain-boot into a corrupted Windows system without the user noticing. For all of these reasons, a number of developers seem to feel that this is a place where the kernel community should maybe push back rather than letting Microsoft dictate the terms under which a system can boot on UEFI hardware. But some of Red Hat's developers, in particular, seem to be genuinely afraid of the prospect of a key revocation by Microsoft; Dave Airlie put it this way:

Others counter that, if Microsoft can revoke keys for any reason, there is little to be done to protect the kernel in any case.

In the end, this does not appear to be an easy disagreement to resolve, though some parts are easy enough: Linus has refused to accept the key-loading patch, so it will not be merged. What may well happen is that the patch will drop out of sight, but that distributors like Red Hat will quietly include it in their kernels. That will keep this particular disagreement from returning to the kernel development list, but it does little to resolve the larger question of how much Linux developers should be driven by fear of Microsoft's power as they work to support the UEFI secure boot mechanism.

Comments (42 posted)

Patches and updates

Kernel trees

• Greg KH: Linux 3.7.10 . (February 27, 2013)

• Herton Ronaldo Krzesinski: Linux 3.5.7.6 . (February 27, 2013)

• Greg KH: Linux 3.4.33 . (February 21, 2013)

• Steven Rostedt: 3.4.33-rt47 . (February 26, 2013)

• Steven Rostedt: 3.4.32-rt46 . (February 22, 2013)

• Steven Rostedt: 3.2.39-rt59 . (February 26, 2013)

• Steven Rostedt: 3.2.38-rt58 . (February 22, 2013)

• Greg KH: Linux 3.0.66 . (February 21, 2013)

• Steven Rostedt: 3.0.66-rt93 . (February 26, 2013)

• Steven Rostedt: 3.0.65-rt92 . (February 22, 2013)

Build system

• Kyungsik Lee: Add support for LZ4-compressed kernel . (February 26, 2013)

Core kernel code

• Pavel Emelyanov: [PATCH 0/3] posix timers: Extend kernel API to report more info about timers (v2) . (February 22, 2013)

• Thomas Gleixner: [RFC patch 0/8] timekeeping: Implement shadow timekeeper to shorten in kernel reader side blocking . (February 22, 2013)

• Daniel Lezcano: time: dynamic irq affinity . (February 27, 2013)

Development tools

• Steven Rostedt: tracing: Addition of multiple buffers . (February 27, 2013)

Device drivers

• Mauro Carvalho Chehab: Add a driver to report Firmware first errors (via GHES) . (February 21, 2013)

• sjur.brandeland@stericsson.com: remoteproc: Support bi-directional vdev config space . (February 21, 2013)

• Kim, Milo: backlight: add new LP8788 backlight driver . (February 25, 2013)

• Hauke Mehrtens: brcmsmac: add AP mode . (February 26, 2013)

• Simon Glass: Add ChromeOS Embedded Controller support . (February 26, 2013)

• Andrey Smirnov: Driver for Si476x series of chips . (February 26, 2013)

• Paul Zimmerman: DWC2 DesignWare HS OTG driver . (February 27, 2013)

• Guenter Roeck: hwmon: Driver for Nuvoton NCT6775F, NCT6776F, and NCT6779D . (February 27, 2013)

• Rafael J. Wysocki: ACPI / hotplug: Common code for ACPI-based hotplug . (February 27, 2013)

• Benjamin Tissoires: HID: multitouch: support of hybrid finger/pen devices . (February 27, 2013)

Filesystems and block I/O

• Nathan Zimmer: procfs: Improve Scaling in proc . (February 25, 2013)

Memory management

• Naoya Horiguchi: extend hugepage migration . (February 22, 2013)

• Roman Gushchin: memcg: implement low limits . (February 27, 2013)

Networking

• Eliezer Tamir: net: low latency Ethernet device polling . (February 27, 2013)

Architecture-specific

• Benson Leung: Platform: x86: chromeos_laptop - Add support for Chromebook Pixel . (February 22, 2013)

• Aneesh Kumar K.V: THP support for PPC64 . (February 26, 2013)

Security-related

• David Howells: Load keys from signed PE binaries . (February 27, 2013)

Miscellaneous

• Stephen Hemminger: iproute2 3.8.0 . (February 21, 2013)

Page editor: Jonathan Corbet

Distributions

The Ubuntu Touch experience

As promised, Canonical released installable versions of its upcoming "Ubuntu Touch" distribution for a small set of devices on February 21. Your editor, being in possession of a Galaxy Nexus phone just waiting for an obscure firmware load, decided to give it a try. Running Ubuntu on a telephone is an interesting and refreshing experience, but Canonical has quite a bit of ground to cover before Ubuntu Touch will be competitive with the other offerings on the market now.

Installing the firmware image is a relatively easy thing to do, especially if one happens to have an Ubuntu desktop system sitting around. One simply adds the "phablet-team/tools" repository, installs a few packages, plugs in an (unlocked) device, then runs "phablet-flash". The operation failed with a mysterious message on the first attempt, but the second worked fine. The biggest negative effect (other than wiping all the data on the phone, which was expected) is the lingering distaste that the term "phablet" leaves in one's mouth. One can only hope that word will soon fade into well-deserved obscurity.

The device boots fairly quickly into an Ubuntu-themed lock screen, shown on the left. The "social" focus of the distribution is made clear by the claim on the lock screen that 14 tweets have been received — interesting news to your editor who had not yet informed the device about his Twitter account. Indeed, he has yet to get around to creating a Twitter account to tell the phone about. The lock screen, like much of this release, is a mock-up, doomed to proclaim those 14 tweets forevermore. The installed system also comes complete with fake messages, contacts, appointments, and more; your editor initially thought that some data had leaked from a developer's device, but that data's inclusion is deliberate. The hope is to give a feel for what working with the device will be like when all the expected functionality is present.

Getting out of the lock screen is not as obvious an operation as one might expect the first time around. Ubuntu Touch is heavily based on "swipe" gestures; a swipe from each edge of the screen yields a different result. In the lock screen, swiping from the left produces a variant of the familiar Unity icon bar; swiping from the right drops the phone into whatever application was running when the lock screen took over. Swipes from the right will switch applications when the lock screen is not present; a swipe from the bottom will usually produce some sort of application-specific screen (sometimes nothing happens at all), often with a search bar in it. The left-edge swipe gesture will normally cause the Unity bar to make a brief, useless, and confusing appearance while the home screen array shows up.

Your editor says "array" because the home screen is actually five screens: from left to right they are devoted to music, people (messages and appointments), a "home home" screen with a mix of everything from "favorite apps" to "videos popular online" (shown on the right), applications, and videos. Yes, "music" and "videos" are as far apart as possible, and, yes, those screens will happily sell you stuff to listen to or watch. Or, at least, the video screen will; the music screen is blank. How does one move between these screens? By dragging them to the left or right, of course. One just has to be careful to drag from somewhere other than the edge, or the phone interprets the gesture as one of the above-described swipe operations instead. Suffice to say it is easy to end up with the wrong operation.

At the top is a typical status/notification bar; swiping down from the top edge provides access to the controls found underneath. There are several sets of controls to be obtained this way, each behind one of the small icons in the top bar. It is easy for a fat-fingered user to get the wrong one, making the interface a little frustrating. Most of the controls are relatively self-explanatory. The screen brightness control lives behind the battery icon, which may be surprising to some.

On the subject of the battery: the device's battery life when running Ubuntu is horrendous, on the order of a few hours. In a way, that is surprising; Ubuntu is using the Android kernel for this device (actually, amusingly, it's the CyanogenMod 3.0.31 kernel) so there should not be significant power management problems at that level. The obvious conclusion is that Ubuntu's user space is running the battery down. Perhaps that user space is not well integrated with Android's wakelock mechanism at this point; it is hard to say. Power consumption should be a solvable problem, in any case.

In general, the Ubuntu Touch experience is rather unpolished at this point; there are enough rough edges that one would be well advised to wear gloves while working with the interface. The keyboard goes into an immortal mode where only rebooting the device will make it go away; the fact that the keycaps are always shown in upper case despite the keyboard's mode also makes it harder to use. There is no word completion or spelling correction in this release. The photo gallery has no "pinch zoom" feature. There appears to be no provision for using the screen in the landscape orientation at all. A number of the applications are false fronts; the weather application looks nice, but only if one is interested in what was happening in Las Vegas on January 8. The device is often sluggish in its response and gets worse the longer it runs. And so on. But this is a preview image, it's expected to be that way.

Does it function as a phone? There is no signal strength indicator or any other sign that the phone is on a cellular network. But, surprisingly enough, the phone function works, in that the device can make and receive calls and send SMS messages. The dialer is rudimentary but functional; it has some quirks, though, like the decision that the dial pad and the mute button will not be accessible at the same time. Mobile data does not work, though, but WiFi does. There is no working Bluetooth functionality.

The camera application is also rudimentary, but it is able to take pictures. The flash works, and the application can use the sensors on both the front and back of the phone. There is a video-recording mode, but it does not work. There is no provision for panoramic photos, "scene" modes, or any of the other fancy features that have found their way into the Android camera in recent times. There is a basic WebKit-based browser that works, along with a GMail application; there is no provision for reading email hosted anywhere else. There is no way to install third-party applications in this preview; one assumes that capability will be well supported by the time Ubuntu Touch becomes a real product.

Given that the system is running on an Android base, an obvious question comes to mind: why not install the Dalvik runtime and support Android applications? That would immediately bring a wide range of applications to the device. No such feature exists now, though, and your editor would guess that no such thing is forthcoming. Ubuntu may hope to make money directly with its distribution for mobile devices, but, one suspects, it is control over the application ecosystem that really brings the dollar signs to Mark Shuttleworth's eyes. So, naturally, Canonical will want to remain in control of media and application purchases so that it can get its cut. The company's motivation is straightforward, but the result is a system that cannot take advantage of all the mobile applications that already exist.

One nice feature of running an Ubuntu-based distribution is that there is a full Ubuntu command-line user space available. There is no terminal emulator application on the device, but the Android adb utility can be used to obtain a shell; after that, it is possible to install and run an SSH server. The full Ubuntu repository is available; the phone appeared to be happy to install Eclipse when asked, for example (your editor, not being a total fool, canceled the operation). The X Window System is included in the image, but, since the display is not running X (it runs Android's SurfaceFlinger), X applications cannot be run. In the end, though, having a full Linux system on the device is refreshing; it feels more like home.

As of this writing, images for the Galaxy Nexus and Nexus 4 phones are available; there are also images for the Nexus 7 and Nexus 10 tablets. Canonical would clearly like to support a much wider range of hardware, though, especially if it can get the community to help out with the porting work. Developers interested in hacking on Ubuntu Touch on other devices can consult the detailed porting guide. A quick look at the work in progress list suggests that a number of developers have already taken up this challenge.

Ubuntu Touch is an ambitious move by Canonical. The mobile world is already dominated by two established systems with other contenders (Tizen and Firefox OS, for example) about to enter the fray. But it is also where a lot of the interesting action is. If Ubuntu can be successful here, it may well bring Linux to the "desktop" in a way that has proved elusive with traditional computers. Getting there will require a lot of work, though. Patience with half-finished products is not high in the consumer electronics world; all of those rough edges and missing applications will need to be taken care of before Ubuntu Touch can be presented as a real product. Only then can the difficult task of convincing vendors to build hardware around this distribution begin. But, if all that can be made to happen, Canonical might just earn itself a place in this market.

Comments (6 posted)

Brief items

Distribution quotes of the week

-- jspaleta

-- Greg KH

Comments (none posted)

The first arm64 Debian image is available

Wookey has announced the availability of the first version of the Debian operating system that works on the 64-bit ARM architecture. "Enough packages were built for arm64 to debootstrap an image which booted to a prompt! After a bit of fettling (and switching to multistrap) I got an image with all the packages configured which boots with upstart to a login prompt (I admit, I did get quite excited about this, as it represents the coming together of nearly 3 years work on multiarch, crossbuilding, bootstrapping, cyclic dependencies and arm64)." Most of us will have to wait a while to try this image, though, since arm64 hardware is not yet available.

Full Story (comments: 14)

Updated Debian 6.0: 6.0.7 released

Debian has released the seventh update of its stable distribution (6.0/squeeze). "This update mainly adds corrections for security problems to the stable release, along with a few adjustments for serious problems. Security advisories were already published separately and are referenced where available."

Full Story (comments: none)

Mandriva unveils the Mandriva Business Server

Mandriva SA has released the Mandriva Business Server. "Mandriva Business Server is the new enterprise platform of Mandriva and has thus been developed with enhanced security and modularity “by design”. As a platform Mandriva Business Server ships with the Mandriva ServicePlace, an integrated app store allowing third party professional solutions to be tested and deployed on Mandriva Business Server."

Comments (none posted)

MINIX 3.2.1 released

MINIX 3.2.1 has been released. See the release notes for details. "3.2.1 boasts significantly more polish again in terms of base-system expansion and cleanup, in areas such as userland utilities, libraries, the build system, but also drivers and kernel improvements, various performance improvements, and more."

Comments (54 posted)

Red Hat Enterprise Linux 6.4 released

Red Hat has announced the release of Red Hat Enterprise Linux 6.4. New features include scale-out data access through pNFS, identity management tools, enhanced interoperability, and more. See the release notes for details.

Comments (none posted)

Ubuntu for phone/tablet available

As promised, Canonical has released binary images of its distribution for phones (Galaxy Nexus and Nexus 4) and tablets (Nexus 7/10). "The Ubuntu Touch Developer Preview is intended to be used for development and evaluation purposes only. It does not provide all of the features and services of a retail phone and cannot replace your current handset. This preview is the first release of a very new and unfinished version of Ubuntu and it will evolve quickly."

Comments (15 posted)

Newsletters and articles of interest

Distribution newsletters

• DistroWatch Weekly, Issue 496 (February 25)
• ROSA Planet
• Ubuntu Weekly Newsletter, Issue 305 (February 24)

Comments (none posted)

Fuduntu: An Innovative Old Linux Revisited (Linux Insider)

Linux Insider has a favorable review of Fuduntu. "Fuduntu gives you a frustration-free user experience on desktop computers, as well as laptops and netbooks, with up-to-date applications. This latest release even includes an installer for the beta of the Steam For Linux software distribution service."

Comments (1 posted)

Meet Manjaro Linux (PCWorld)

PCWorld takes a look at Manjaro Linux, a user-friendly Arch Linux derivative. "For those on the more experienced end, however, Manjaro offers extensive customizability to suit personal taste and preference. In addition, there's also a minimalist NET-Edition stripped of any preinstalled software that can be used as a base installation on which to build your own system. " Manjaro 0.8.4 was released this week.

Comments (none posted)

Page editor: Rebecca Sobol

Development

Namespaces in operation, part 5: User namespaces

Continuing our ongoing series on namespaces, this article looks more closely at user namespaces, a feature whose implementation was (largely) completed in Linux 3.8. (The remaining work consists of changes for XFS and a number of other filesystems; the latter has already been merged for 3.9.) User namespaces allow per-namespace mappings of user and group IDs. This means that a process's user and group IDs inside a user namespace can be different from its IDs outside of the namespace. Most notably, a process can have a nonzero user ID outside a namespace while at the same time having a user ID of zero inside the namespace; in other words, the process is unprivileged for operations outside the user namespace but has root privileges inside the namespace.

Creating user namespaces

User namespaces are created by specifying the CLONE_NEWUSER flag when calling clone() or unshare(). Starting with Linux 3.8 (and unlike the flags used for creating other types of namespaces), no privilege is required to create a user namespace. In our examples below, all of the user namespaces are created using the unprivileged user ID 1000.

To begin investigating user namespaces, we'll make use of a small program, demo_userns.c, that creates a child in a new user namespace. The child simply displays its effective user and group IDs as well as its capabilities. Running this program as an unprivileged user produces the following result:

    $ id -u          # Display effective user ID of shell process
    1000
    $ id -g          # Effective group ID of shell
    1000
    $ ./demo_userns 
    eUID = 65534;  eGID = 65534;  capabilities: =ep

The output from this program shows some interesting details. One of these is the capabilities that were assigned to the child process. The string "=ep" (produced by the library function cap_to_text(), which converts capability sets to a textual representation) indicates that the child has a full set of permitted and effective capabilities, even though the program was run from an unprivileged account. When a user namespace is created, the first process in the namespace is granted a full set of capabilities in the namespace. This allows that process to perform any initializations that are necessary in the namespace before other process are created in the namespace.

The second point of interest is the user and group IDs of the child process. As noted above, a process's user and group IDs inside and outside a user namespace can be different. However, there needs to be a mapping from the user IDs inside a user namespace to a corresponding set of user IDs outside the namespace; the same is true of group IDs. This allows the system to perform the appropriate permission checks when a process in a user namespace performs operations that affect the wider system (e.g., sending a signal to a process outside the namespace or accessing a file).

System calls that return process user and group IDs—for example, getuid() and getgid()—always return credentials as they appear inside the user namespace in which the calling process resides. If a user ID has no mapping inside the namespace, then system calls that return user IDs return the value defined in the file /proc/sys/kernel/overflowuid, which on a standard system defaults to the value 65534. Initially, a user namespace has no user ID mapping, so all user IDs inside the namespace map to this value. Likewise, a new user namespace has no mappings for group IDs, and all unmapped group IDs map to /proc/sys/kernel/overflowgid (which has the same default as overflowuid).

There is one other important point worth noting that can't be gleaned from the output above. Although the new process has a full set of capabilities in the new user namespace, it has no capabilities in the parent namespace. This is true regardless of the credentials and capabilities of the process that calls clone(). In particular, even if root employs clone(CLONE_NEWUSER), the resulting child process will have no capabilities in the parent namespace.

One final point to be made about the creation of user namespaces is that namespaces can be nested; that is, each user namespace (other than the initial user namespace) has a parent user namespace, and can have zero or more child user namespaces. The parent of a user namespace is the user namespace of the process that creates the user namespace via a call to clone() or unshare() with the CLONE_NEWUSER flag. The significance of the parent-child relationship between user namespaces will become clearer in the remainder of this article.

Mapping user and group IDs

Normally, one of the first steps after creating a new user namespace is to define the mappings used for the user and group IDs of the processes that will be created in that namespace. This is done by writing mapping information to the /proc/PID/uid_map and /proc/PID/gid_map files corresponding to one of the processes in the user namespace. (Initially, these two files are empty.) This information consists of one or more lines, each of which contains three values separated by white space:

    ID-inside-ns   ID-outside-ns   length

Together, the ID-inside-ns and length values define a range of IDs inside the namespace that are to be mapped to an ID range of the same length outside the namespace. The ID-outside-ns value specifies the starting point of the outside range. How ID-outside-ns is interpreted depends on the whether the process opening the file /proc/PID/uid_map (or /proc/PID/gid_map) is in the same user namespace as the process PID:

• If the two processes are in the same namespace, then ID-outside-ns is interpreted as a user ID (group ID) in the parent user namespace of the process PID. The common case here is that a process is writing to its own mapping file (/proc/self/uid_map or /proc/self/gid_map).
• If the two processes are in different namespaces, then ID-outside-ns is interpreted as a user ID (group ID) in the user namespace of the process opening /proc/PID/uid_map (/proc/PID/gid_map). The writing process is then defining the mapping relative to its own user namespace.

Suppose that we once more invoke our demo_userns program, but this time with a single command-line argument (any string). This causes the program to loop, continuously displaying credentials and capabilities every few seconds:

    $ ./demo_userns x
    eUID = 65534;  eGID = 65534;  capabilities: =ep
    eUID = 65534;  eGID = 65534;  capabilities: =ep

Now we switch to another terminal window—to a shell process running in another namespace (namely, the parent user namespace of the process running demo_userns) and create a user ID mapping for the child process in the new user namespace created by demo_userns:

    $ ps -C demo_userns -o 'pid uid comm'      # Determine PID of clone child
      PID   UID COMMAND 
     4712  1000 demo_userns                    # This is the parent
     4713  1000 demo_userns                    # Child in a new user namespace
    $ echo '0 1000 1' > /proc/4713/uid_map

If we return to the window running demo_userns, we now see:

    eUID = 0;  eGID = 65534;  capabilities: =ep

In other words, the user ID 1000 in the parent user namespace (which was formerly mapped to 65534) has been mapped to user ID 0 in the user namespace created by demo_userns. From this point, all operations within the new user namespace that deal with this user ID will see the number 0, while corresponding operations in the parent user namespace will see the same process as having user ID 1000.

We can likewise create a mapping for group IDs in the new user namespace. Switching to another terminal window, we create a mapping for the single group ID 1000 in the parent user namespace to the group ID 0 in the new user namespace:

    $ echo '0 1000 1' > /proc/4713/gid_map

Switching back to the window running demo_userns, we see that change reflected in the display of the effective group ID:

    eUID = 0;  eGID = 0;  capabilities: =ep

Rules for writing to mapping files

There are a number of rules governing writing to uid_map files; analogous rules apply for writing to gid_map files. The most important of these rules are as follows.

Defining a mapping is a one-time operation per namespace: we can perform only a single write (that may contain multiple newline-delimited records) to a uid_map file of exactly one of the processes in the user namespace. Furthermore, the number of lines that may be written to the file is currently limited to five (an arbitrary limit that may be increased in the future).

The /proc/PID/uid_map file is owned by the user ID that created the namespace, and is writeable only by that user (or a privileged user). In addition, all of the following requirements must be met:

• The writing process must have the CAP_SETUID (CAP_SETGID for gid_map) capability in the user namespace of the process PID.
• Regardless of capabilities, the writing process must be in either the user namespace of the process PID or inside the (immediate) parent user namespace of the process PID.
• One of the following must be true:

• The data written to uid_map (gid_map) consists of a single line that maps (only) the writing process's effective user ID (group ID) in the parent user namespace to a user ID (group ID) in the user namespace. This rule allows the initial process in a user namespace (i.e., the child created by clone()) to write a mapping for its own user ID (group ID).
• The process has the CAP_SETUID (CAP_SETGID for gid_map) capability in the parent user namespace. Such a process can define mappings to arbitrary user IDs (group IDs) in the parent user namespace. As we noted earlier, the initial process in a new user namespace has no capabilities in the parent namespace. Thus, only a process in the parent namespace can write a mapping that maps arbitrary IDs in the parent user namespace.

Capabilities, execve(), and user ID 0

In an earlier article in this series, we developed the ns_child_exec program. This program uses clone() to create a child process in new namespaces specified by command-line options and then executes a shell command in the child process.

Suppose that we use this program to execute a shell in a new user namespace and then within that shell we try to define the user ID mapping for the new user namespace. In doing so, we run into a problem:

    $ ./ns_child_exec -U  bash
    $ echo '0 1000 1' > /proc/$$/uid_map       # $$ is the PID of the shell
    bash: echo: write error: Operation not permitted

This error occurs because the shell has no capabilities inside the new user namespace, as can be seen from the following commands:

    $ id -u         # Verify that user ID and group ID are not mapped
    65534
    $ id -g
    65534
    $ cat /proc/$$/status | egrep 'Cap(Inh|Prm|Eff)'
    CapInh: 0000000000000000
    CapPrm: 0000000000000000
    CapEff: 0000000000000000

The problem occurred at the execve() call that executed the bash shell: when a process with non-zero user IDs performs an execve(), the process's capability sets are cleared. (The capabilities(7) manual page details the treatment of capabilities during an execve().)

To avoid this problem, it is necessary to create a user ID mapping inside the user namespace before performing the execve(). This is not possible with the ns_child_exec program; we need a slightly enhanced version of the program that does allow this.

The userns_child_exec.c program performs the same task as the ns_child_exec program, and has the same command-line interface, except that it allows two additional command-line options, -M and -G. These options accept string arguments that are used to define user and group ID maps for the new user namespace. For example, the following command maps both user ID 1000 and group ID 1000 to 0 in the new user namespace:

    $ ./userns_child_exec -U -M '0 1000 1' -G '0 1000 1' bash

This time, updating the mapping files succeeds, and we see that the shell has the expected user ID, group ID, and capabilities:

    $ id -u
    0
    $ id -g
    0
    $ cat /proc/$$/status | egrep 'Cap(Inh|Prm|Eff)'
    CapInh: 0000000000000000
    CapPrm: 0000001fffffffff
    CapEff: 0000001fffffffff

There are some subtleties to the implementation of the userns_child_exec program. First, either the parent process (i.e., the caller of clone()) or the new child process could update the user ID and group ID maps of the new user namespace. However, following the rules above, the only kind of mapping that the child process could define would be one that maps just its own effective user ID. If we want to define arbitrary user and group ID mappings in the child, then that must be done by the parent process. Furthermore, the parent process must have suitable capabilities, namely CAP_SETUID, CAP_SETGID, and (to ensure that the parent has the permissions needed to open the mapping files) CAP_DAC_OVERRIDE.

Furthermore, the parent must ensure that it updates the mapping files before the child calls execve() (otherwise we have exactly the problem described above, where the child will lose capabilities during the execve()). To do this, the two processes employ a pipe to ensure the required synchronization; comments in the program source code give full details.

Viewing user and group ID mappings

The examples so far showed the use of /proc/PID/uid_map and /proc/PID/gid_map files for defining a mapping. These files can also be used to view the mappings governing a process. As when writing to these files, the second (ID-outside-ns) value is interpreted according to which process is opening the file. If the process opening the file is in the same user namespace as the process PID, then ID-outside-ns is defined with respect to the parent user namespace. If the process opening the file is in a different user namespace, then ID-outside-ns is defined with respect to the user namespace of the process opening the file.

We can illustrate this by creating a couple of user namespaces running shells, and examining the uid_map files of the processes in the namespaces. We begin by creating a new user namespace with a process running a shell:

    $ id -u            # Display effective user ID
    1000
    $ ./userns_child_exec -U -M '0 1000 1' -G '0 1000 1' bash
    $ echo $$          # Show shell's PID for later reference
    2465
    $ cat /proc/2465/uid_map
             0       1000          1
    $ id -u            # Mapping gives this process an effective user ID of 0
    0

Now suppose we switch to another terminal window and create a sibling user namespace that employs different user and group ID mappings:

    $ ./userns_child_exec -U -M '200 1000 1' -G '200 1000 1' bash
    $ cat /proc/self/uid_map
           200       1000          1
    $ id -u            # Mapping gives this process an effective user ID of 200
    200
    $ echo $$          # Show shell's PID for later reference
    2535

Continuing in the second terminal window, which is running in the second user namespace, we view the user ID mapping of the process in the other user namespace:

    $ cat /proc/2465/uid_map
             0        200          1

The output of this command shows that user ID 0 in the other user namespace maps to user ID 200 in this namespace. Note that the same command produced different output when executed in the other user namespace, because the kernel generates the ID-outside-ns value according to the user namespace of the process that is reading from the file.

If we switch back to the first terminal window, and display the user ID mapping file for the process in the second user namespace, we see the converse mapping:

    $ cat /proc/2535/uid_map
           200          0          1

Again, the output here is different from the same command when executed in the second user namespace, because the ID-outside-ns value is generated according to the user namespace of the process that is reading from the file. Of course, in the initial namespace, user ID 0 in the first namespace and user ID 200 in the second namespace both map to user ID 1000. We can verify this by executing the following commands in a third shell window inside the initial user namespace:

    $ cat /proc/2465/uid_map
             0       1000          1
    $ cat /proc/2535/uid_map
           200       1000          1

Concluding remarks

In this article, we've looked at the basics of user namespaces: creating a user namespace, using user and group ID map files, and the interaction of user namespaces and capabilities.

As we noted in an earlier article, one of the motivations for implementing user namespaces is to give non-root applications access to functionality that was formerly limited to the root user. In traditional UNIX systems, various pieces of functionality have been limited to the root user in order to prevent unprivileged users from manipulating the runtime environment of privileged programs, which could affect the operation of those programs in unexpected or undesirable ways.

A user namespace allows a process (that is unprivileged outside the namespace) to have root privileges while at the same time limiting the scope of that privilege to the namespace, with the result that the process cannot manipulate the runtime environment of privileged programs in the wider system. In order to use these root privileges meaningfully, we need to combine user namespaces with other types of namespaces—that topic will form the subject of the next article in this series.

Comments (16 posted)

Brief items

Quote of the week

— Michael Stahl (hat tip to Cesar Eduardo Barros)

Comments (40 posted)

Ruby 2.0.0 released

Version 2.0.0 of the Ruby language is now available. "Ruby 2.0.0 is the first stable release of the Ruby 2.0 series, with many new features and improvements in response to the increasingly diverse and expanding demands for Ruby." Changes include keyword arguments, UTF-8 encoding by default, a number of new libraries, some performance improvements, and more. See this article for more information about the changes in this release.

Comments (13 posted)

Django 1.5 released

Version 1.5 of the Django web framework is available; new features include a new configurable user model, Python 3 support, a lot of documentation improvements, and more; see the release notes for details.

Comments (8 posted)

Subsurface 3.0 has been released

Dirk Hohndel has announced the release of Subsurface 3.0, the open source dive-logging program. Improvements include map display of GPS locations, a dive planner, automatic dive numbering, and support for many new dive computers.

Full Story (comments: none)

BIND10 1.0.0 available

Version 10.0 of BIND has been released. Although known to many as a DNS server, BIND 10 provides a number of additional features, including "dynamic DNS, zone transfers, and experimental forwarding and recursive name service," plus statistics collection, reporting, and remote configuration. Among the many changes are DDNS (Dynamic Updates) support, an SQLite3 backend, and a "semi-interactive client to conveniently look at and set some configuration settings."

Full Story (comments: none)

GNOME 3.7.90 beta development release

GNOME 3.7.90, the first beta release of the development cycle that will eventually become GNOME 3.8, is now available. Lengthy changelogs for both the core and the base applications are available.

Full Story (comments: none)

Newsletters and articles

Development newsletters from the past week

• Caml Weekly News (February 26)
• What's cooking in git.git (February 21)
• What's cooking in git.git (February 26)
• Haskell Weekly News (February 20)
• Openstack Community Weekly Newsletter (February 22)
• Perl Weekly (February 25)
• PostgreSQL Weekly News (February 24)
• Ruby Weekly (February 21)

Comments (none posted)

Digital show and tell video from Xiph.org

Xiph.org, the purveyors of widely-used open audio and video codecs, has released Digital Show and Tell, a video demonstrating facets of digital audio processing such as "of sampling, quantization, bit-depth, and dither show digital audio behavior on real audio equipment using both modern digital analysis and vintage analog bench equipment... just in case we can't trust those newfangled digital gizmos." Accompanying the video is source code with which interested viewers can reproduce the demos shown.

Full Story (comments: 1)

Page editor: Nathan Willis

Announcements

Brief items

LG acquires webOS from HP

LG and HP have announced that LG has acquired the webOS system, including source code, patents, "engineering talent," and more. LG will be taking over the Open webOS and Enyo open-source projects; there is no indication of how enthusiastically the company will support those projects, though.

Comments (3 posted)

Mozilla announces 18 carriers supporting Firefox OS

Mozilla has announced that eighteen carriers have "committed" to Firefox OS. "The breadth of operators now backing Mozilla’s Firefox OS demonstrates significant industry support for a fully-adaptable, unconstrained mobile platform.The first wave of Firefox OS devices will be available to consumers in Brazil, Colombia, Hungary, Mexico, Montenegro, Poland, Serbia, Spain and Venezuela. Additional markets will be announced soon." Handsets will be made by Alcatel, Huawei, LG, and ZTE.

Comments (50 posted)

The 2013 "State of X.Org" report

The X.Org secretary has posted the annual report on the state of the X.Org Foundation. "The Wayland project gained some momentum in 2012. The Board has agreed that supporting Wayland, Mesa, and other affiliated X.Org projects is a high priority. Some envision a Wayland-based future for open source graphical infrastructure; the Board's role is to ensure that open source graphical environments have a healthy future, whatever technical direction the community chooses to pursue."

Full Story (comments: 23)

Articles of interest

EFF: Open Letter to House Judiciary - Investigate Patent Trolls

The Electronic Frontier Foundation (EFF) has written an open letter to the US House Committee on the Judiciary asking for relief from patent trolls. "The letter expresses the coalition's support for the SHIELD (Saving High-Tech Innovators from Egregious Legal Disputes) Act, a bipartisan bill from Rep. Peter DeFazio and Rep. Jason Chaffetz that would create real and appropriate consequences for patent lawsuit abuse. Under the Act, if a patent troll loses in court because the patent is found to be invalid or there is no infringement, then the troll pays the other side's legal costs, which often reach into the millions of dollars."

Full Story (comments: 19)

RIP Mark Crispin

Wikipedia's biography on Mark Crispin notes that he passed away last December. "Mark Reed Crispin (born July 19, 1956 in Camden, New Jersey; died December 28, 2012 in Poulsbo, Washington) is best known as the father of the IMAP protocol, having invented it in 1985 during his time at the Stanford Knowledge Systems Laboratory. He is the author or co-author of numerous RFCs; and is the principal author of UW IMAP, one of the reference implementations of the IMAP4rev1 protocol described in RFC 3501. He also designed the mix mail storage format." The news of the illness that led to his death was posted on the imap5 mailing list. (Thanks to Jonathan Abbey)

Comments (1 posted)

SCALE 11X: One for the record books

The Southern California Linux Expo (SCALE) team wraps up another successful event. "Many of the sessions had full attendance, and some were in overflow status. A testament to the quality of the presentations during the course of SCALE 11X is that some of the final presentations on Sunday afternoon were also full." Videos should be available soon.

Full Story (comments: none)

New Books

Blender Master Class--New from No Starch Press

No Starch Press has released "Blender Master Class" by Ben Simonds.

Full Story (comments: none)

Education and Certification

LPI: Linux Essentials meets CSTA K-12 standards

The Linux Professional Institute (LPI) has announced that its Linux Essentials program has met the requirements of the K-12 Computer Science Standards of the Computer Science Teachers Association (CSTA). ""Given the educational imperatives that exist today in the United States, this is an important first step to ensure innovative Linux and Open Source technologies are included as part of the regular K-12 curriculum. This will greatly assist educators in their efforts to develop the professional IT workforce of the future. LPI applauds the CSTA on this initiative and is proud to be the first educational resource accepted by the CSTA Curriculum Committee as a resource crosswalk," said Jim Lacey, president and CEO of LPI."

Full Story (comments: none)

Upcoming Events

Ubuntu Developer Summit To Be Held Online, More Frequently (OMG Ubuntu)

The OMG Ubuntu site reports that the well-regarded Ubuntu Developer Summit is being transformed into an online-only event. "In the age of Google+ hangouts and real-time collaboration the notion of flying people around the world to spend a week in each others company seems antiquated and inefficient."

Update: see this announcement from Jono Bacon for more information. "With the fantastic level of interest in the recent phone and tablet announcements, we decided that we couldn’t wait until May to run this new format for UDS, so the first online UDS will be taking place next week from 5th - 6th March 2013 from 4pm UTC - 10pm UTC."

Comments (19 posted)

LibrePlanet 2013

LibrePlanet 2013: "Commit Change" takes place March 23-24 in Cambridge, MA. It's gratis for FSF members and discounted for students, but registration is required.

Full Story (comments: none)

FSFE: Document Freedom Day: 2013

The Free Software Foundation Europe will be celebrating Document Freedom Day on March 27. "Document Freedom Day (DFD) campaigns to celebrate information accessibility and introduce non-technical audiences to Open Standards. Open Standards are a basic condition for freedom and choice in software; ensuring the freedom to access data, and the freedom to build Free Software to read and write information. Started in 2008, the campaign last year had 54 events worldwide."

Full Story (comments: none)

Velocity 2013

Velocity 2013, the O'Reilly Web Performance and Operations Conference, will take place June 18-20 in Santa Clara, California. Registration is open and the program has been announced.

Full Story (comments: none)

Events: February 28, 2013 to April 29, 2013

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
February 25 March 1	ConFoo	Montreal, Canada
February 26 February 28	ApacheCon NA 2013	Portland, Oregon, USA
February 26 February 28	O’Reilly Strata Conference	Santa Clara, CA, USA
February 26 March 1	GUUG Spring Conference 2013	Frankfurt, Germany
March 4 March 8	LCA13: Linaro Connect Asia	Hong Kong, China
March 6 March 8	Magnolia Amplify 2013	Miami, FL, USA
March 9 March 10	Open Source Days 2013	Copenhagen, DK
March 13 March 21	PyCon 2013	Santa Clara, CA, US
March 15 March 16	Open Source Conference	Szczecin, Poland
March 15 March 17	German Perl Workshop	Berlin, Germany
March 16 March 17	Chemnitzer Linux-Tage 2013	Chemnitz, Germany
March 19 March 21	FLOSS UK Large Installation Systems Administration	Newcastle-upon-Tyne , UK
March 20 March 22	Open Source Think Tank	Calistoga, CA, USA
March 23	Augsburger Linux-Infotag 2013	Augsburg, Germany
March 23 March 24	LibrePlanet 2013: Commit Change	Cambridge, MA, USA
March 25	Ignite LocationTech Boston	Boston, MA, USA
March 30	Emacsconf	London, UK
March 30	NYC Open Tech Conference	Queens, NY, USA
April 1 April 5	Scientific Software Engineering Conference	Boulder, CO, USA
April 4 April 5	Distro Recipes	Paris, France
April 4 April 7	OsmoDevCon 2013	Berlin, Germany
April 6 April 7	international Openmobility conference 2013	Bratislava, Slovakia
April 8	The CentOS Dojo 2013	Antwerp, Belgium
April 8 April 9	Write The Docs	Portland, OR, USA
April 10 April 13	Libre Graphics Meeting	Madrid, Spain
April 10 April 13	Evergreen ILS 2013	Vancouver, Canada
April 14	OpenShift Origin Community Day	Portland, OR, USA
April 15 April 17	Open Networking Summit	Santa Clara, CA, USA
April 15 April 17	LF Collaboration Summit	San Francisco, CA, USA
April 15 April 18	OpenStack Summit	Portland, OR, USA
April 16 April 18	Lustre User Group 13	San Diego, USA
April 17 April 18	Open Source Data Center Conference	Nuremberg, Germany
April 17 April 19	IPv6 Summit	Denver, CO, USA
April 18 April 19	Linux Storage, Filesystem and MM Summit	San Francisco, CA, USA
April 19	Puppet Camp	Nürnberg, Germany
April 22 April 25	Percona Live MySQL Conference and Expo	Santa Clara, CA, USA
April 26	MySQL® & Cloud Database Solutions Day	Santa Clara, CA, USA
April 27 April 28	LinuxFest Northwest	Bellingham, WA, USA
April 27 April 28	WordCamp Melbourne 2013	Melbourne, Australia

If your event does not appear here, please tell us about it.

Page editor: Rebecca Sobol