Leading items

On the boundaries of GPL enforcement

Last October, the Software Freedom Conservancy (SFC) and Free Software Foundation (FSF) jointly published "The Principles of Community-Oriented GPL Enforcement". That document described what those organizations believe the goal of enforcement efforts should be and how those efforts should be carried out. Several other organizations endorsed the principles, including the netfilter project earlier this month. It was, perhaps, a bit puzzling that the project would make that endorsement at that time, but a July 19 SFC blog post sheds some light on the matter.

There have been rumblings for some time about a kernel developer doing enforcement in Germany that might not be particularly "community-oriented", but public information was scarce. Based on the blog post by Bradley Kuhn and Karen Sandler, though, it would seem that Patrick McHardy, who worked on netfilter, is the kernel developer in question. McHardy has also recently been suspended from the netfilter core team pending his reply to "severe allegations" with regard to "the style of his license enforcement activities".

The SFC post is a bit more specific about what McHardy has been accused of:

There is, it seems, a subculture of GPL enforcement out there that is effectively doing enforcement for profit:

It is not clear whether McHardy is among the GPL monetizers or not, though there is seemingly no evidence that his efforts have led to any code being released. In addition, repeated attempts by both SFC and the netfilter team to discuss his enforcement efforts have not been answered—or even acknowledged. According to the blog post, the SFC invited McHardy to join in the drafting of the principles. That invitation went unanswered, as did another to endorse the principles after they were published. Amid the accusations from companies about his actions, some kind of response to SFC or the netfilter team would seem to make sense. The absence of that response speaks volumes, at least to some.

In fact, if McHardy disagrees with some parts of the principles, the SFC has invited him (or others who are enforcing the GPL) to "publicly propose updates or modifications to the Principles". There is a new mailing list available to host those kinds of discussions.

But if, in fact, the enforcement actions taken by McHardy are being done as a for-profit exercise, it is hard to see what response he could make. He is under no real obligation to work with others who are also enforcing the license. If he disagrees with the principles, engaging with the community about his objections would certainly be welcome, but it is apparently not a priority for him.

It is a topic that should be discussed in our communities, however, and the release of the principles was partly meant to foster that discussion. What should the primary goal of enforcement be? Should companies be "punished" for violating the GPL and, if so, how? If compliance is the goal, how should enforcement activities be funded? And so on.

When the SFC began a fundraising campaign to support its GPL enforcement efforts late last year, some were incredulous that enforcement was not self-sustaining. But prioritizing sustainability has dangers of its own, from taking money to overlook compliance problems to holding up settlements even after the company has come into compliance over monetary issues. If the goal is to get the software released, as the philosophical underpinnings of the GPL imply, then compliance should clearly be the overarching consideration.

There are elements that would like to see the GPL not be enforced at all, of course. In effect, that turns the GPL into the BSD license, which has plenty of implications of its own. There is no real way to know how much the GPL has helped in the rise of Linux versus its non-copylefted alternatives, but it would be hard to argue that the license played no role whatsoever.

If enforcement were to stop, at least in the community-oriented sense, what would be the effect on the companies that work hard (and spend lots of money) to ensure their compliance with the license? They would largely be safe from any for-profit shakedown enforcement efforts, but those with deep pockets are generally already safe from those tactics.

As with many things in open-source communities, there are lots of different—sometimes conflicting—opinions about license enforcement, its benefits and drawbacks, and so forth. There is room for trying multiple approaches, but enforcement, at least under the principles that have been defined so far, is not an inexpensive proposition. That suggests that either some of the deep-pocketed organizations in our communities step up or that we continue muddling along on the current path.

The lack of any real consensus on license enforcement, especially within the commercial side of the community, does leave room for some to abuse the process. Some of that is already happening, but success in GPL shakedowns could lead to more participants. There is a risk of a huge wave of copyright trolls using the GPL to extract money from companies, which would not be a pleasant outcome.

In the end, license enforcement is up to the collective copyright holders; if most of those are happy with the current state of affairs, it is hard to see how things will change. The GPL is meant to level the playing field, so that all participants have the same rights—and responsibilities—to the code. But if that playing field is seen as "level enough", even while GPL violations abound, enforcement may well be seen by major players as more trouble than it is worth.

Comments (13 posted)

Snap interfaces for sandboxed applications

Last week, we took a look at the initial release of the "portal" framework developed for Flatpak, the application-packaging format currently being developed in GNOME. For comparison, we will also explore the corresponding resource-control framework available in the Snap format developed in Ubuntu. The two packaging projects have broadly similar end goals, as many have observed, but they tend to vary quite a bit in the implementation details. Naturally, those differences are of particular importance to the intended audience: application developers.

There is some common ground between the projects. Both use some combination of techniques (namespaces, control groups, seccomp filters, etc.) to restrict what a packaged application can do. Moreover, both implement a "deny by default" sandbox, then provide a supplemental means for applications to access certain useful system resources on a restricted or mediated basis. As we will see, there is also some overlap in what interfaces are offered, although the implementations differ.

Snap has been available since 2014, so its sandboxing and resource-control implementations have already seen real-world usage. That said, the design of Snap originated in the Ubuntu Touch project aimed at smartphones, so some of its assumptions are undergoing revision as Snap comes to desktop systems.

In the Snap framework, the interfaces that are defined to provide access to system resources are called, simply, "interfaces." As we will see, they cover similar territory to the recently unveiled "portals" for Flatpak, but there are some key distinctions.

Two classes of Snap interfaces are defined: one for the standard resources expected to be of use to end-user applications, and one designed for use by system utilities. Snap packages using the standard interfaces can be installed with the snap command-line tool (which is the equivalent of apt for .deb packages). Packages using the advanced interfaces require a separate management tool.

The standard interfaces defined as of the Ubuntu 16.04 release are:

• network: which provides access to the network
• network-bind: which allows the package to run a server bound to a network port
• unity7: which allows the package to access the Unity 7 desktop environment's services (such as notifications, the application menu, and the input-method switcher)
• x11: which allows the package to access the X server
• pulseaudio: which allows playback-only access to the PulseAudio sound server
• opengl: which allows access to the machine's OpenGL hardware
• home: which allows access to non-hidden files in the user's $HOME directory
• gsettings: which allows the package to access the user's GSettings data
• optical-drive: which provides read-only access to the first optical drive in the system
• mpris: which mediates access to Media Player Remote Interfacing Specification (MPRIS) programs
• camera: which provides access to the first video camera on the system

From that list, the unity7, x11, opengl, home, and gsettings interfaces are "reserved," meaning that Snap packages using these features will be reviewed when they are submitted for inclusion in Ubuntu's Snap repository. No such review takes place for individual .snap files that a user acquires and installs on their own, of course. Perhaps a more relevant safeguard is that the home, mpris, and camera interfaces do not allow the application to auto-connect: manual approval by the user is required.

The mpris interface is special for another reason, in that Snap packages can register themselves as either a "slot" (that is, a service provider) or a "plug" (that is, an MPRIS controller). So a remote-control application would register as a plug, while a music server would register as a slot.

In all other cases, the slot end of the interface is an existing system facility, and permission to access it is governed by some aspect of the sandbox. For example, device control groups are used to provide access to hardware. A device control group is created for each application; an application using the camera interface will have /dev/video0 included in its control group, while default applications will not.

By default, every Snap application is confined to a sandbox defined with a generic AppArmor policy. Each interface that is enabled layers on an additional AppArmor policy that enables the capabilities required for the chosen service. The interfaces requested by the application are listed in its package manifest, which is read by the package installer.

Every executable in a Snap package receives its own security label, of the form snap.packagename.command, which can be used to audit application behavior at a per-executable level, in addition to implementing the relevant access controls. A command-line tool is available that will show all installed Snap packages and which interfaces each has subscribed to; it can also be used to disconnect a package from an interface.

It is also worth pointing out, however, that AppArmor is not explicitly required in order to run the Snap system. The default sandbox policy and the per-interface policies could be defined for SELinux or some other Linux Security Module (LSM). Doing so in a consistent manner across several LSMs would require careful policy writing, of course. Zygmunt Krynicki has recently been working on an SELinux implementation intended to enable Snap packages to run on Fedora and Arch Linux.

The advanced interfaces include:

• cups-control: which provides access to the Common UNIX Printing System (CUPS) control socket
• firewall-control: which allows the application to configure the firewall
• locale-control: which allows the application to alter the system locale
• log-observe: which allows the application to read system logs and to change the rate-limiting of kernel logs
• mount-observe: which enables the application to read filesystem-mount information
• network-control: which allows the application to configure networking
• network-observe: which lets the application query network status
• serial-port: which provides access to serial ports
• snapd-control: which allows the application to manage Snap packages
• system-observe: which allows the application to query system information
• timeserver-control: which allows the application to manage timeservers

The advanced interfaces seem to be derived, in large part, from Snap's origin as the package system for Ubuntu Touch. As a result, there is not yet a desktop tool provided to enable installation or management of Snap packages that request access to these interfaces.

Comparisons

An interesting distinction between Snap and Flatpak is that Flatpak has, so far, placed greater emphasis on user intervention as a means of mediating access to system resources. Six of Flatpak's initial ten portals require the user to approve resource-access requests, while only three of Snap's interfaces do the same. The portal model mimics the "Intents" system used by Android, in which a system process mediates each sensitive request from the sandboxed app—asking the user to verify the request interactively, then relaying the response back to the app.

So far, Snap's model has worked more like "app permissions" in Android; the installation tool asks the user to approve usage of the requested interface. When reached for comment, though, Ubuntu's Ted Gould said he thought it likely that Snap on the desktop would eventually move to a more interactive process.

There are a number of other differences in the security models employed by Flatpak and Snap, so a direct comparison is of limited value. For instance, all Snap packages get access to a per-application private directory in which they can store files. Consequently, some of the need for Flatpak's Documents portal is alleviated.

As a separate example, Snap's unity7 interface includes all of the desktop environment's services, while Flatpak's Screenshot, Inhibit, and Notification portals provide granular access to separate desktop features. But, on the flip side, Snap packages can include multiple executables, each of which has its own list of specified interfaces. Thus, a GUI application might be configured for a limited set of interfaces, while a related management tool might request additional access to the system.

In other words, while Flatpak provides per-feature granularity of certain services, Snap offers finer-than-package-level granularity for interfaces. Which is more useful to developers may depend on whom one asks.

Looking forward

Snap, like Flatpak, is undergoing heavy development, and the development version of the system already supports several additional interfaces that were not released with Ubuntu 16.04. The new additions include interfaces for Bluetooth access, geolocation, and accessing ModemManager. In addition, quite a few other interface proposals are being tracked in the project's issue tracker, including interfaces for working with power-management information, GPIOs, and Industrial I/O (IIO).

It remains to be seen whether or not Flatpak's portals and Snap's interfaces will evolve toward a set of consistent (if not identical) resource-control definitions. Certainly some of the existing portals and interfaces implement similar ideas. And several of the portals proposed by developers working on Flatpak implement features already covered in Snap interfaces.

Developers would certainly benefit from having similar sets of permissions to consider when creating their packages—as, no doubt, would end users. Anyone familiar with the recent history of desktop Linux distributions may find it hard to muster any hope that the two projects will attempt to arrive at compatible solutions, of course. But it is still early in the process for both projects, and the importance of sandboxed desktop application packages seems to be well-understood by all. So perhaps the projects can at least drift toward a common goal.

Comments (1 posted)

Anonymous publishing with Riffle

Preserving anonymity online is an understandably hot topic these days. But it can be confused with related concepts like privacy and secure communication. A new protocol called Riffle was recently published [PDF] by researchers at MIT; it offers a different take on anonymity than that implemented by other projects. A Riffle network could be used to implement an anonymous but verifiable blogging or publishing platform: one in which the messages are visible to everyone, but the identity of all users remains hidden.

For comparison, the most well-known anonymity project is, no doubt, Tor, which enables users to access Internet services without revealing their physical location on the network. It is possible to use Tor to access publishing services like Twitter and, thus, to broadcast content to the Internet at large without revealing one's identity. But Tor is just as useful at solving other problems, such as accessing remote servers that are blocked by a firewall. While important, that usage of Tor does not necessarily involve anonymity; one could, for instance, use it to log in to Facebook, and Tor alone does not prevent the use of web trackers by sites.

Furthermore, Tor is the focus of near-constant attacks (against the network itself and against the algorithms that keep it working), and it may be vulnerable to large-scale traffic analysis—such as a national ISP could perform. One of the stated goals of Riffle is to prevent such traffic analysis, which has led to popular reports and online discussions referring to Riffle as a Tor competitor.

But Riffle, in fact, tackles a narrower problem set. In a Riffle network, every message sent or file uploaded is eventually published in plaintext form where everyone can see it. The Riffle protocol offers strong guarantees that the identity of the message's uploader cannot be discovered—even in cases where multiple servers in the network have been compromised.

Background

The system builds on two existing ideas: verifiable shuffles [PDF] and dining cryptographer networks (DC-nets). Verifiable shuffles enable a server to reorder a set of incoming messages before sending them back out in a seemingly random sequence, while allowing the participants to verify that all of the output messages correspond to the inputs. In particular, participants can verify that all of their messages were delivered and that no phony messages were inserted.

Such shuffle algorithms generate a reordered sequence of messages as well as a proof that can be used to verify the validity of the shuffling step, but that cannot be used to reverse-engineer the permutation used. They can also be employed by pools of servers in so-called "mixnets." That makes network traffic difficult to analyze in the hopes of discovering who sent any particular message (thus guarding against Tor's weakness), but it comes at an inconveniently high computational cost.

DC-nets provide strong anonymity by having each node in the network transmit a message that is cryptographically mixed with the message of a neighbor node, which is then mixed with the message of that node's neighbor, and so forth. The pairwise mixing of messages also makes it impossible for cheaters to crack the encryption unless they control every node. But DC-nets require every node to send traffic in every round, and they do not scale well because the message channel is broadcast-only: all messages are passed around to all participants, making poor use of the available bandwidth. With more than a few dozen participants, throughput slows to a crawl.

The Dissent system was able to overcome some of traditional DC-nets' limitations by splitting the nodes into server and client classes. The servers (presumably higher-end hardware) can take care of the verifiable shuffle without imposing that computational burden on the clients. Dissent also altered the trust model versus traditional DC-nets (in which every node participated in the message-passing step), letting the servers shoulder much of that burden as well. The authors demonstrated that, as long as at least one server remains uncompromised, clients could trust the entire Dissent server pool. Nevertheless, the authors of the Riffle paper said, Dissent still slows down proportionally as more users join the network.

Riffle

Riffle is, in many respects, an iteration on Dissent designed to overcome that system's bandwidth-sharing problem. Like Dissent, Riffle has servers and clients. But clients each consume only bandwidth proportional to their own message size. Furthermore, the computational load on the servers is reduced, with the intensive verifiable-shuffle calculations only performed on periodic occasions (such as when the set of available servers changes).

The bandwidth reduction is accomplished by using different upload and download mechanisms. When a client sends a message, it is placed into the network's verifiable-shuffle system. When a client downloads messages, it uses a separate private information retrieval (PIR) protocol.

In the setup phase, each server first generates a public key pair and publishes the public key to all of the clients. The servers in the server pool also generate a set of permutations they will use for the verifiable shuffle and exchange proofs with the other servers. Once setup is complete, however, the servers continue to use this fixed shuffle, alleviating the need to compute a new shuffle for every round of messages, as was done in traditional verifiable-shuffle mixnets.

In the communication phase, each client onion-encrypts its outgoing message—meaning that the message is encrypted, in turn, with the public key of each server. But each client opens a channel to just one server and sends it the onion-encrypted message, breaking it into fixed-size chunks to better obscure message size.

Next, each server decrypts the message chunks it has received using its private key, then shuffles the chunks and relays them to the next server. ElGamal keys are used for the onion-encryption stage because they are commutative; the servers in the pool can each decrypt the message they see using their own key, and the order of the original encryption does not affect the output. Once the messages reach the last server in the pool, they have been decrypted by every private key and are now plaintext.

Finally, the clients download the messages they want using PIR. In this scheme, the server pool publishes an index of the chunks available at each server, and the clients request a random set of indexes that includes the messages it is interested in. That way, each client can only use as much bandwidth as it desires; if some other client has uploaded a large document, other clients are not obligated to download it. The authors of the paper note, however, that the PIR step is not critical to the rest of the system; if a shared message channel is preferable, users could simply run Riffle in a broadcast manner instead.

The computational savings occur because Riffle does the setup phase only once per "epoch," which entails the verifiable-shuffle computations by the servers, and uses less expensive TLS channels to exchange all other content. What constitutes an epoch is not strictly defined; whenever a new server leaves or joins the pool, the server will have to re-do the verifiable-shuffle setup, but the network could be configured to periodically start a new epoch for added security.

The paper goes on to demonstrate that Riffle is resistant to the same attacks that verifiable-shuffle mixnets and older DC-nets protect against. The real question is whether or not the new system results in a scheme that can scale better to large networks. The authors cite tests showing that Riffle can achieve an average bandwidth of 100KBps for a network of 200 clients when tuned for file-sharing usage. Tuning for speed instead, as one might do for a Twitter-style microblogging network, the authors claim to support a network of 10,000 clients with a message latency of less than one second.

The Riffle paper's main author, Albert Kwon, has released a prototype implementation on GitHub, which he called "performance accurate (but probably not security accurate)". The repository includes client and server code, both written in Go, but it, regrettably, does not have any license attached.

There are clearly plenty of interesting ideas to be found in Riffle, although at this point it is hard to say whether or not the paper or its concepts will have a practical impact on projects like Tor. One subscriber did post links to the Riffle paper to the tor-talk mailing list, but it has elicited no discussion so far.

It is easy to speculate that some of Riffle's components (such as verifiable shuffles) could potentially be added to Tor, and might even be beneficial. But perhaps Riffle will prove most interesting to developers tackling different problems altogether. There might be uses for a Twitter-like microblogging service that has strong anonymity baked in from the start, or for an anonymous file-sharing network. Either of those use cases could prove to be a valuable tool for end users, without requiring use of the more general-purpose Tor network.

Comments (2 posted)