What’s new and exciting with SELinux and security in the new 2.6.26 kernel? Expanding some of the items from the excellent Kernel Newbies 2.6.26 page:

• security= boot parameter
  This patch by Ahmed Darwish allows a particular security module to be selected at kernel boot time, so that distributions can ship multiple security modules and allow the user to decide which one (if any) to enable. For example: security=selinux selects SELinux, while security=smack selects SMACK. (In Fedora, you don’t need to do anything: SELinux is the default).
• New SELinux open permission
  Until now, opening a file under SELinux invoked the same permission checks as the intended operation on the file, such as read, write, execute and append. There was no separate “open” check: opening a file for write, for example, was considered by SELinux policy as equivalent to actually writing to the file. Experience has shown that this approach is not ideal for handling cases such as IO redirection via the shell, because policy writers cannot usefully guess where users will send redirected output. This is a very common use-case for Linux, so a solution is most definitely necessary, while also preserving strong security. Can it be done? Yes!

  Implemented by Eric Paris, the new open permission provides a way to address the issue by providing applications with liberal access to read/write/execute/append permissions but tightly locking down the ability to open a file. In the case of redirecting output via the shell:

  bash# /sbin/do-stuff > /tmp/output

  the shell forks and creates /tmp/output, calls dup2(2) to replace stdin with the newly created file descriptor, then execs do-stuff. With the old permissions, do-stuff would have required an SELinux write permission on the new file, which it very likely would not have had. By providing do-stuff with liberal file access permissions, but not the new open permission, its output may now be redirected to the file without needing to give it the ability to directly open the file. The invoking shell of course needs the open permission, which it effectively delegates to do-stuff via the open file descriptor.

  Updated security policy which utilizes this technique should be available soon in rawhide, and integrated into Fedora 10, providing significant usability improvements for sysadmins and power users.

• Permissive Types
  Also implemented by Eric, permissive types (aka permissive domains) allows permissive mode to be selected on the fly on a per-domain basis. Permissive mode is where security policy is being checked and logged, but not actually enforced, and was previously only possible on a system-wide basis. By making this per-domain, applications which are experiencing SELinux policy issues may be flipped into permissive mode, allowing them to do what they need until a proper fix is available, without disabling policy enforcement for the rest of the system.

• Network Port SID Cache
  Paul Moore implemented a cache to improve the performance of the SELinux networking code, so that network port labels are no longer looked up in the (typically large) kernel policy database on a per-packet basis, and is instead retrieved from an RCU-based cache. This addresses a long standing network performance issue which has been observed with very high loads on network servers.

There’s quite a lot happening in security for 2.6.27, some of which has already been merged into Linus’ tree. Due to the pervasive nature of some of the patches (including David Howells’ credentials rework), I’m feeding all of the SELinux stuff via my security-testing tree. The “devel” branch is where bleeding edge changes are initially stabilized before being applied to the “next” branch, which is in turn fed into to linux-next.

I presented on the SELinux project today at the Linux Foundation Japan Symposium in Tokyo. The slides from my talk may be downloaded here.

It’s been an interesting conference, with some smaller BoF sessions planned for tomorrow. I live micro-blogged the conference via my identi.ca account, which I guess turned out as a kind of public note-taking.

Andrew Morton covered quite a lot of interesting kernel process material, highlighting some areas which we need to address (such as whether we’re ready at all to support solid state disks), and explaining his view of the linux-next tree, one unpublished purpose of which was to get kernel hackers to test each others code before upstream merge. He also said that around 15% of kernel contributions are now coming from Japan.

Greg DeKoenigsberg kindly shipped a pile of Fedora DVDs and Live CDs across to give to the attendees. The CDs & DVDs proved very popular and were all distributed.

More photos here.

I’ll be giving a talk on the SELinux project at the next Linux Foundation Symposium in Japan, to be held 9th and 10th of July. Details of the symposium are here in Japanese, while a PDF schedule in English lives here.

From the abstract for my talk:

This talk will provide an overview of the project, covering its rationale, design goals, and milestones. Recent significant developments and ongoing work will be discussed. The aim of the talk is to help the audience better understand SELinux and how it might be utilized to implement a diverse range of security goals.

A specific topic I’d like to cover at some level is expectations. There’s no silver bullet for security, and likely never will be, unless perhaps the OS is redesigned from scratch with all applications coded in a security-aware language, and people totally change the way they use computers.

The concept—endlessly proposed by snake-oil merchants—that security can be dramatically improved without any disruption to the user experience, is unrealistic. A practical approach will involve attempting to avoid disruption as much as possible, and to find optimal ways of handling difficult cases. It will not pretend there is no complexity.

As an analogy, consider network firewalling, where you are able to obtain an increased level of protection against several common threats by configuring a packet filter to only allow expected traffic. This may break some previously common use-cases, such as ad-hoc deployment of new network services, unless the user learns how to reconfigure the packet filter. Even with a high-level GUI tool, some fundamental understanding of networking and security is still required for the user to be able to make informed use of the tool.

There is very little history of significant adoption of improved security without a change to the user experience. Even in what may be the most successful case—the migration from telnet and R commands to SSH—people had to gain new knowledge, master new skills, and change their behaviour. Even with the relative simplicity of SSH and ubiquitous availability of implementations, there are still mission critical systems using telnet over unprotected networks, which should surprise nobody working in the real world. Before sighing wearily, consider how so many smart people can still get it so wrong.

Security is hard. Real improvements only come with continuous effort and innovation, where innovation is not just “inventing” but also transforming the practice of a community. It does not happen overnight, nor even overyear. Recall the various iterations of packet filtering in Linux prior to the integration of Netfilter in the 2.4 kernel, along with the R&D effort around firewalls before Linux even existed. It seems to me that it takes around a decade for substantial change to occur, including the changes to both the technology and the culture.

There may not be the time to dive too deeply into this topic during the talk itself, although I’m sure there’ll be plenty of opportunities for conversations during the always important hallway and after-hours sake tracks.

Also speaking:

• Thomas Gleixner on the Completely Fair Scheduler
• Paul Moore on Labeled Networking
• Toshiharu Harada on the experience of trying to get TOMOYO upstreamed
• Andrew Morton (tentatively) on kernel stuff

There are BoF sessions on the second day covering security, the kernel scheduler and general kernel discussion.

After that, I’ll be back in Sydney for a few days before flying to Ottawa for OLS and the SELinux developer summit.

I’ve set up a tumbleblog here:

http://jamesmorris.tumblr.com/

essentially as a kind of public bookmarking of things which I find interesting, without much in the way of commentary (if any).

If you want to follow it, grab the rss feed. The topics will likely vary beyond the typically work-related stuff I post here, although still somewhat geeky & security-ish. I’d suggest not adding the feed to public blog aggregation sites.

An insightful essay from Bruce Schneier: How to Sell Security.

He discusses the tendency for people to subjectively evaluate risk and tend toward taking greater chances with losses:

When faced with a gain, about 85 percent of people chose the sure smaller gain over the risky larger gain. But when faced with a loss, about 70 percent chose the risky larger loss over the sure smaller loss.

This is from an experiment demonstrating Prospect Theory, which interestingly predicts that people will tend to take greater risks for higher-probability losses.

Bruce talks about how this leads to a problem in the selling of security features, where people are inclined—according to prospect theory—to be increasingly risk-taking as the security threat increases. One option, which is favored in certain areas of the industry, is to fuel fear, although this approach has obvious ethical issues, and I think ultimately, damages credibility and becomes effectively counterproductive. Rather:

The better solution is not to sell security directly, but to include it as part of a more general product or service. Your car comes with safety and security features built in; they’re not sold separately. Same with your house. And it should be the same with computers and networks. Vendors need to build security into the products and services that customers actually want.

Bingo.

SELinux was a factor in the recently announced NYSE Euronext adoption of Linux:

NYSE Euronext also relies on Red Hat Enterprise Linux and its included Security-Enhanced Linux (SELinux) functionality to preserve the security of its platform. With trillions of dollars flowing through the exchange each month, security is a large and very important organizational focus. “We are very security conscious because we have to be. The operating system is a key part of every server that we operate and each server must be secure at all times. We maintain the security of our systems by relying on the SELinux features within Red Hat Enterprise Linux,” said Rubinow.

Their system handles US$141 billion per day in trades.

In case you hadn’t noticed, Fedora 9 has been released. One of the many goodies to be included is SLIDE: the SELinux policy development IDE. This should be great news for application developers who want their projects to work well with SELinux.

It’s been possible for some time now to quickly develop a loadable policy module when an application clashes with the shipped SELinux policy. The technique is quite simple: parse the audit log and generate rules which allow the previously denied accesses. This is a form of “learning mode”, which risks encapsulating badness and being incomplete. It’s often handy for resolving local issues, but not necessarily the kind of thing that a developer would want to use for creating shippable and maintainable policy.

This is where SLIDE comes in. It’s an eclipse-based environment with deep knowledge of the SELinux policy infrastructure, facilitating policy development for everything from the simplest application through to the general system policy. It’s not “SELinux policy for Dummies”, but it does provide some useful high-level abstractions such as wizards. Developers who are interested in learning more about how to develop policy for their applications can now easily get started with SLIDE in Fedora 9. If not installed already, do so:

$ sudo yum install eclipse-slide selinux-policy-devel

SLIDE should then be available via Applications -> Programming -> Eclipse. Start a new project and follow the prompts to create a policy module for an application. The application doesn’t even need to exist—this is simply a good way to learn about the policy framework. Note that the location of reference policy is /usr/share/selinux/devel/include.

Here are some screenshots (click for larger images):

Creating a new policy module via the wizard.

Guided interface. These fields are automatically populated, while elements may be expanded out for greater control.

Automatically generated initial policy ready for building or further development.

It would be immensely useful now to have a simple worked tutorial to help people get started in a practical manner. I’m not sure if anyone is planning to do this currently, so if you’re looking for a way to dive in and contribute to the project, please get in touch via the mailing list. Otherwise, please wait until it falls from the sky.

Have fun!

Via a the Chennai ILUG mailing list, here’s an interesting story: Linux rides pillion on Mumbai city buses. I like how this system uses GPS to figure the cost of each trip, rather than alternatives such as a single fare or complicated fare schemes.

Deployed in January 2007, the system is so stable that it will this month be officially extended to part of Mumbai’s suburban railways as well. It is also secure, and has had no hacks and cracks, according to Kaizen.

Thanks to the system’s use of Linux, BEST saved about inr 1.2 million on the point of sale infrastructure alone, as compared with a Microsoft Windows setup, Goriani says.

It’s also slightly reassuring to see they’re moved from telnet to SSH for remote management.

Sydney recently canned a smartcard-based bus ticketing system after spending AUD$95 million. Given that the same company was developing both systems (as well as the system for Singapore), and that such systems are fairly commonplace in modern cities, I think you could reasonably surmise that the problems in the Sydney system were not technical.

Dave Quigley has just submitted an Internet Draft to the IETF outlining the requirements for Labeled NFS:

MAC Security Label Requirements for NFSv4 (link)

Abstract

This Internet-Draft outlines high-level requirements for the
integration of flexible Mandatory Access Control (MAC) functionality
into NFSv4.1 . It describes the level of protections that should be
provided over protocol components and the basic structure of the
proposed system. It also gives a brief explanation of what kinds of
protections MAC systems offer and why existing NFSv4 protection
mechanisms are not sufficient.

This draft is a generalization the original Security Enhanced NFS document posted last year, addressing the general need for mandatory access control support in NFS.

NFSv4 currently supports two access control schemes: standard DAC and ACLs. MAC labeling support is required for technologies such as SELinux and OpenSolaris FMAC.

Essentially what’s needed is a way to convey MAC labels over the wire (for both setting and retrieving their values), and to be able to enforce security policy using those labels. The server needs to be able to determine the security label of the remote client process when enforcing policy, and all systems need to be able to ensure they understand each other’s labels, or be able to translate them. A “Domain of Interpretation” (DOI) attribute is used to determine the meaning of labels, a term which may be familiar to those who’ve braved the IPsec specifications. The confidentiality and integrity of these security attributes must be protected in transit, while all parties need to be authenticated. We also need to be able to handle the case where either the client or server does not have MAC enabled, and to ensure non-breakage with existing implementations. There’s a lot more in the details, but that’s the gist of it.

It may seem at first glance that NFSv4 named attributes (NAs) would provide the required labeling functionality, but they’re not a good fit. NAs are specifed as opaque to the system and user-managed, while MAC security labels are managed by the system. NAs also do not provide necessary semantics such as conveying client security attributes or negotiation of DOI. There are also issues with attribute namespaces (which are user-managed and unspecified) and labeling atomicity. Another possible approach is to implement Linux/BSD-style extended attributes (EAs), which are simple text string attributes associated with files, in contrast with the NA “subfile” scheme. This would potentially only solve the attribute namespace issue, and is also not a good general solution. EAs are also not currently part of the NFSv4 specification, and it seems like a contentious area in any case.

The current Labeled NFS prototype code utilizes NFSv4 recommended attributes (RAs), which are fully extensible, already exist, and are already used for similar management of metadata (e.g. ACLs). This seems to be the simplest and most straightforward approach.

Once there’s consensus on the requirements, the next step will be to develop a protocol specification and hopefully have it incorporated into NFSv4. v4.1 is currently in “last call”, so the next candidate would be v4.2, it seems. The prototype code for Linux/SELinux will continue to be developed alongside the standards process.

For those interested in following or contributing to the project, there are several relevant mailing lists:

• Labeled NFS
• IETF NFSv4
• Linux NFS

Dave is hoping to have further discussion IETF 72 in July, and will be presenting on the state of the project at the SELinux Developer Summit ahead of that.

We managed to get the SELinux developer summit schedule published a few days early. Hopefully, this will help people who are making travel arrangements to OLS.

As mentioned, a lot of high quality proposals were submitted. To ensure that all important topics can be covered, the format of the summit has been changed to moderated discussion panels with presentations; rather than the original plan of having a set of fixed-length presentations followed by discussion panels.

Presentations will now be 10-20 minutes, with a greater focus on discussion. This provides much more flexibility, and is derived somewhat from experience with the kernel networking summit, which has been very successful with short presentations driving discussions.

The panel sessions are as follows:

• Community
• Applications
• Desktop
• Distributed Technologies
• Policy Configuration
• Policy Infrastructure
• Emerging Technology/Works in Progress

More detailed information, including topics, issues, and links to abstracts may be found at the schedule page. Also see the printable version and the topics page.

All SELinux developers and folk with a technical interest in SELinux and related technologies are welcome to attend. Don’t forget that you also need to be registered to attend OLS.