2006 SELinux Developer Summit

Purpose

The purpose of the developer summit was to provide a forum for focused, detailed technical discussion of ongoing development and future plans for SELinux among core SELinux developers and contributors.

Attendees

• Matt Anderson, HP
• Thomas Bleher
• Joshua Brindle, Tresys / Gentoo
• James Carter, NSA
• Janak Desai, IBM
• Lorenzo Hernandez Garcia-Hierro
• Darrel Goeddel, TCS
• Steve Grubb, Red Hat
• Serge Hallyn, IBM
• Chad Hanson, TCS
• Trent Jaeger, Penn State Univ
• Daniel Jones, IBM
• KaiGai Kohei, NEC
• Peter Loscocco, NSA
• Karl MacMillan, Tresys
• Frank Mayer, Tresys
• Paul Moore, HP
• James Morris, Red Hat
• Yuichi Nakamura, Hitachi Software / GWU
• Chris PeBenito, Tresys / Gentoo
• John Ramsdell, MITRE
• Chad Sellers, Tresys
• Doc Shankar, IBM
• Stephen Smalley, NSA
• Brian Sniffen, MITRE
• Manoj Srivastava, Debian
• Dan Walsh, Red Hat
• Klaus Weidner, AtSec
• George Wilson, IBM

Agenda

Opening Session

• Welcome and introductions.
• Discussion of topics of general concern and miscellaneous topics.

• Discussion of ongoing and planned development in the areas of policy languages, tools, frameworks, and infrastructure.

• Discussion of ongoing and planned development to meet LSPP/RBAC/CAPP requirements, particularly as it affects SELinux.

Note: It was originally planned to run the policy development and LSPP/RBAC/CAPP sessions in parallel during the day, with a report back/summary sessions at the end. However, a number of attendees expressed a desire to participate in both sessions, so they were instead run serially, enabling all attendees to participate in both sessions and eliminating the need for a separate report-back/summary session.

General and Miscellaneous Topics

The summit began with an hour-long opening session to reiterate the purpose and focus of the summit, introduce the participants, and cover several general and miscellaneous topics. The topics that were actually covered during the initial session included pan-distribution support, securing the desktop, and NFS integration. Later in the day another general topic, network access controls, was also raised between the later sessions, which is also summarized below.

Pan-Distribution Support

The first topic of discussion was on the issue of improving pan-distribution support for SELinux and creating a more viable upstream SELinux development community that is not so closely coupled to Fedora. This would both help other distributions like Debian to integrate SELinux and track changes in the SELinux code and help to reduce the maintenance burden currently being carried primarily by the Fedora package maintainers for the SELinux userland patches. It would also facilitate getting more of the SELinux userland patches into the upstream packages where there is still an active upstream maintainer.

Tresys Technology indicated that they already planned to create a site for hosting their own projects and expressed a willingness to host other core SELinux components in the same manner. This could potentially include the core SELinux userland, SELinux userland patches for various packages, packaging meta-data like spec files, debian files, and ebuilds. It was suggested that distribution-specific branches (writable by the packager for the distribution) would be helpful for items such as the coreutils SELinux patch, since each distribution already carries a large number of coreutils changes and they likely cannot share the exact same patch but would still benefit from greater visibility into changes in the SELinux support of other distributions. Different revision control systems were discussed, but Tresys plans to use subversion for their own trees and it would be easiest if this could be used for all projects on the site. Using a separate .org name for the site was recommended to emphasize the community nature of the site. Tresys will proceed to set up the site and announce it when available.

James Morris has also set up a selinuxnews.org site with SELinux news and also created a "Planet SELinux" blog aggregator there for SELinux developers. This is a useful way of disseminating and archiving important developments and information about SELinux to the larger community.

Securing the Desktop

The second topic of discussion was on securing the desktop. TCS has been carrying the patches for security enhanced X for some time along with corresponding changes to xfce but has not yet upstreamed them. NSA plans to resume work on security enhanced X in July, looking to revisit some of the earlier design decisions and ultimately to get the implementation upstream. NSA is also interested in looking at modifications to other components of the desktop, including the window manager. It was recommended that we seek to team with other organizations on upstreaming of security enhanced X and related development. This work will also be affected by the introduction of dynamic object class and permission discovery for userspace object managers that is being developed by Tresys as part of the policy management server work.

During the desktop discussion, it was asked whether MCS might be a more suitable policy for desktop users, e.g. to get SELinux enabled by default in Debian. However, it was pointed out that MCS is still in its early stages and requires further application integration to be highly useable, and that targeted policy is likely to offer more immediate advantages to typical users without interfering with their ordinary work. It was noted that targeted policy could be selectively "pruned" via boolean settings as desired, so one could ship a targeted policy that confines nothing and then selectively confine specific daemons by adjusting boolean settings.

SELinux NFS integration

A third topic of discussion was on the status of NFS SELinux integration. There is ongoing work upstream to gain proper support for native Linux xattrs in NFSv4, and this is a necessary precursor to SELinux support. It was asked as to whether NFS is truly the right target for the future despite its widespread usage, because NFS extensions won't make their way into legacy systems anyway and the long term outlook for NFS is unclear. CIFS was suggested as another alternative, but the pervasive use of NFS makes it an attractive target. Addendum: James Morris notes that NFS support is important for Xen, with shared storage and nfsroot guests.

Network Access Controls

Between sessions, the topic of enhanced network access controls for SELinux was raised. As background on why enhanced network access controls were desired, it was noted that the existing SELinux network checks only provide pair-based checks over access to ports, network interfaces, and nodes and do not support more complex relationships on entire (port, network interface, node) tuples. They also do not fully address control messages, ephemeral ports, etc.

James Morris described his work on experimental patches to support context-based matching analagous to the existing owner match support in iptables, but noted that owner match in iptables currently only works on outbound packets. Support for incoming packet checking has existed in the form of external patches for some time, but has not yet been upstreamed as it requires some fundamental changes to Netfilter to do properly. Thus, the context-based match patches depend on these infrastructure changes to Netfilter to support general owner matches on inbound packets. There is ongoing work upstream but no definitive time table. The patches by James presently only support exact matches but could be generalized to support a policy-based "match" similar to the recent work on audit filters based on security context, calling into SELinux to perform the actual matching.

It was noted that iptables already has the machinery and expressiveness to address many of the gaps in the SELinux checking, including higher level support like connection tracking, so we want to leverage that machinery as much as possible. However, using iptables userland and config to apply parts of MAC policy splits the overall MAC "policy" into disparate components that need to then be integrated for analysis and management purposes. An alternative model would be to specify labels for arbitrary tuples via SELinux policy and have the SELinux module internally leverage the iptables in-kernel machinery directly to apply the labels and enforce the policy (by using iptables to label packets via MARK and then use regular policy rules to control access based on those labels), so that policy remains centralized and analyzable. On the other hand, this approach is less directly useable by admins (since they are already used to iptables) and in a sense "splits" the iptables policy into two segments. The same issue arises in other spaces as well, e.g. audit-by-context filters, crypto policy integration, etc. The optimal breakdown in responsibility is not entirely clear, but there was a preference toward keeping SELinux policy encapsulated as much as possible (e.g. for policy management server) and distinguishing MAC policy from other kinds of restrictions. It was concluded that we don't necessarily have to limit ourselves to one or the other approach, but could instead do both, i.e. enhance iptables with SELinux support for context-based matches and enhance SELinux to label arbitrary tuples and apply policy to them. However, we do need to ensure that the SELinux policy cannot be made less restrictive by the iptables policy, thereby undermining the MAC policy.

Policy Development Session

The remainder of the morning was spent in the policy development session. This session included discussions on enhancing SELinux useability, enabling effective deployment of policy modules, policy language extensions, and making libsepol the central library for all policy tools and infrastructure.

Useability

This topic began with a discussion of what tools need to be developed to enable the full spectrum of users to effectively use SELinux, ranging from sysadmins to application developers to security admins. Existing tools are primarily oriented toward security admins, although several new tools (SLIDE, Framework, Brickwall, Razor) were released at the time of the symposium that help bridge the gap. Admins never want to see a .te file; application developers might be ok with seeing a .te file but cannot be expected to write one from scratch, and we cannot assume deep knowledge of the application by the same person who is tasked with creating SELinux policy for it. BrickWall is specifically targeted as an easy-to-use solution for sysadmins that avoids need to understand policy. For application developers, SLIDE, CDS Framework, Polgen and Razor are steps in the right direction.

Two gaps were identified in the ability of current users to address SELinux denials effectively: diagnosing the real cause of a SELinux denial (and identifying the proper fix) and proper notification of users of SELinux denials. With regard to the first gap, an enhanced form of audit2why was suggested that could determine the underlying cause of a SELinux denial, including mislabeled files (two cases: mislabeled but restorecon would fix, mislabeled due to mismatch with policy expectations), and propose a possible fix to the user. An analogy to fault tree analysis was suggested, and it was suggested that the fault tree be documented in a wiki based on experience to date. With regard to the second gap, part of the problem has been the migration of audit into audit.log, which has made SELinux less visible to users. The possibility of restoring some logging (in summary form?) via syslog was raised, as well as improved application level logging to identify SELinux-related failures. Desktop notification would be helpful for some users, but can't rely on it in general e.g. for server systems.

To help address the problem of non-standard file locations, the idea of auto-generating policy from existing application configuration files was raised. However, this approach doesn't scale (requires per-application parsers) and would be difficult to maintain (requires tracking of changes to the config file and application).

To help address the problem of preserving security contexts on files, a proposal was made to leverage inotify in order to restore contexts on specific files that are known to commonly have this problem. It was noted that such an approach should not be relied upon as equivalent to proper type transitions or application modifications to preserve contexts; instead, it would serve merely as a fallback mechanism to help recovery and to deal with user-modifiable files like $HOME/public_html.

A general concern was noted that these proposals for automating policy adjustment and file relabeling could themselves become attack vectors and must be carefully protected. For example, automated file relabeling of untrusted-writable directories has obvious security issues that would have to be mitigated.

With regard to helping admins leverage SELinux effectively, it was noted that targeted policy ships with a relaxed configuration in its default boolean settings to avoid breakage for the majority of users, and most admins do not even know to tighten up the booleans for their particular systems, so a suggestion was made to create a Bastille SELinux script to "harden" SELinux boolean settings based on interaction with the admin. There was also discussion of possible collaboration with the Bastille project on meeting DISA STIG guidelines. It was noted that sechecker could support modules to perform certain kinds of checking in this space.

During later discussions between sessions, a proposal was put forth to add support for pathname-based configuration to SELinux by restoring and extending the genfs_contexts functionality, while still internally associating types with the inodes incore. It was noted that the original full genfs_contexts functionality was specifically rejected upstream (and it was only intended to be applied to certain pseudo filesystems as well as to provide defaults for filesystems that do not support labeling, not to replace genuine labeling) when SELinux was mainstreamed into Linux. It was also noted that pathname-based configuration (aside from establishing the initial state of the filesystem, as with file_contexts configuration) is fundamentally flawed in its design regardless of the implementation approach. Paths do not uniquely and unambiguously identify the object or tell us anything about the object's runtime security properties, yield an unbounded number of "policies" that govern access to any given file object (making policy un-analyzable), and make the enforcement of the system policy entirely dependent on the file tree structure and any process with the ability to manipulate the file tree (which is further complicated by support for private namespaces in Linux). Mimicking path-based configuration in SELinux merely encourages people to think of it as a legitimate approach instead of educating them that it is fundamentally flawed. The right path forward is better userspace tools for managing SELinux, including the full range of tools discussed earlier. It was also noted that a inotify-based mechanism could help with parts of this problem (preserving file contexts in problematic cases) without altering the existing kernel mechanisms.

Enabling Effective Deployment of Policy Modules

Most of the work to enable third party policy modules and wider use of policy modules even in the base policy has already been completed (very recently). One lingering issue that was raised again is proper integration with software package management. The requirement that the types be defined in the loaded policy prior to labeling files creates challenges, but is unavoidable (alternatives previously discussed on-list, but rejected). Ideal scenario is for policy for each application package to live in a separate package on which the application package depends, so that policy will naturally be loaded prior to installing the application. Concerns with this idea include significant increases in the number of packages (mitigated in part by the fact that a single policy may cover multiple applications and many applications just run in the user's domain) and the overhead of multiple policy rebuilds and loads when installing multiple packages. The latter can be mitigated by making the package manager aware of the need to batch up multiple policy modules for a single rebuild and load at the beginning of the transaction.

Package removal also poses a problem due to removal of types in the policy causing the incore inode SIDs to be invalidated, leaving them with the unlabeled context. A suggested approach is to instead always replace removed types with typealiases when a module is unloaded so that the types fold down into the base system types and the SIDs remain valid.

It was asked whether the policy devel package was adequate for third party modules. One request was to provide one or more .te files from the refpolicy as examples since most people start writing policy by using an existing .te file as a template.

For contributing to the refpolicy itself, it was requested that an easier method or recipe be provided to reproduce the same working policy tree used for the system policy from the sources without needing to dig through the spec file. This would also likely be helpful to other distributions in reproducing this process in their own package formats. Higher level interfaces were also requested, and are planned now that the base primitives are believed to be correct.

It was noted that the highly modularized strict policy is still broken due to lack of proper ordering of file_contexts entries from the various modules. Discussion on the list pointed toward integrating the ordering algorithm into libsemanage during generation of file_contexts and deprecating the ordering by libselinux matchpathcon, while still retaining a notion of implicit precedence among the base file_contexts vs. .homedirs and .local.

An issue mentioned during the symposium was the need to hide the number of categories, which has been creeping into more configuration files like seusers. Possibly use a category alias (cmax) to avoid having to later modify these files when expanding the number of categories on the system (still need to modify and rebuild the policy, but avoid having to track down multiple locations to update). Another option was to let semanage itself expand the number of categories dynamically upon policy build.

The problem of binary distribution of third party modules was raised due to multiple policy variants (strict, strict-mcs, targeted, targeted-mcs, mls). Proposed solution at present is to use a fat policy package that contains multiple policy modules, and let the tools on the target system extract the right one based on the local policy. Possible link-time interface expansion when interfaces are encoded in language and stored in modules could eliminate this problem; see below.

Policy Language Extensions

Tresys described their proposal for adding interfaces to the policy module language and binary format so that we can have link-time expansion of interfaces rather than just m4 macro expansion at build-time. This proposal is motivated to enable a form of 'dynamic linking' of policy, to reduce the need for parsing macros in tools, and to centralize and codify higher level language constructs. Interfaces would also reduce the need for import of external symbols like types via link-time expansion of interfaces instead, thereby greatly reducing the need for require statements.

No change in the kernel policy format is being proposed, and the proposed changes are purely extensions, leaving the current syntax valid. However, it does include (compatible) changes for the base policy module language, just as the base policy module language had to be extended to support optionals previously. "Static linking" would still be supported via semodule_link.

An example of the syntax of such an interface would be:

interface baz (type $foo, role $bar) {
	allow $foo ...
}

Note that the parameters are explicitly typed and interface names live in a global namespace. There is no planned support for templates yet, although this remains an area of interest (see SENG talk at Symposium). Templates serve as "policy generators" in refpolicy - they generate policy interfaces themselves, and thus raise further issues for link-time expansion. However, we would like to support templates in language, but not yet ready. Desire community input. Start thread on mailing list, follow up with SENG author.

The idea of making interfaces non-global and using the module as a namespace boundary was discussed. A way for a module to ask that multiple interfaces be provided by a single module (rather than split among multiple distinct modules) was requested. It was suggested that ML or Java like interfaces be considered. Other ideas mentioned included support for overloading of interfaces and partial implementations.

Some other extensions include abstractions for permission sets that can be expanded at link-time, but it isn't clear whether these are desirable. A policy module developer usually knows precisely what permissions are needed by his application.

Detailed discussion of the specifics of the language extensions should occur on list.

One other topic in this area was on the need for an extended policy format/meta-data for policy tools to provide ancillary data like line numbers, attribute names, etc. It was asked whether this information should be optionally stored in the base binary module format or via separate auxiliary files ala .debuginfo. Recommendation was to use auxiliary files, possibly in a separate devel package.

Leveraging libsepol

Tresys described a proposal to make libsepol the central library for all policy development, analysis, and infrastructure tools and libraries. This would eliminate the need for duplicated code among the various tool efforts and provide them with a stable ABI. The goal is to also provide the right layer of abstraction to decouple the tools from the low level representation of policy without interfering with their ability to extract detailed information about the policy. The interfaces won't hide things like "rules are stored in a hash table", but would allow the raw data representation to be hidden.

This would then allow libapol (analysis engine from setools) to drop its binary and source policy parsers and their internal representation of policy av rules. Much of the necessary support needed by setools has already been pushed into the policy module format support in libsepol. Version 12 policy support is still needed, but this is not difficult to add.

One issue is where to place the common policy source parser. Putting it into libsepol seems wrong given that libsepol is now a dependency of libselinux (for loading policy) and thus many programs including /sbin/init are dependent on libsepol, and very few programs need the source parser. A small separate library might be suitable, or the existing parser in checkpolicy could be skeletonized (just calls hooks), in which case separate tools could continue to carry copies of the skeleton and just update from checkpolicy periodically, replacing with their own hook function implementations.

The agenda included a topic for development tools integration and cooperation, but there were no specifics to discuss yet beyond agreement that the tools efforts needed to work more closely together.

LSPP/RBACPP/CAPP session

The afternoon was spent in the LSPP/RBACPP/CAPP session. The session began with some discussion of the status of the effort, and a brief comparison with the feature set presently being used by TCS in their product.

It then turned to a discussion of MLS concept of operations for network sessions, including xinetd and sshd behavior, with a particular focus on the need to propagate MLS range restrictions throughout a chain of sessions. For example, ensuring that a ssh localhost after an initial sshd-based login from a remote host that is bounded to a particular range remains bounded properly. xinetd modifications and configuration for range checking still need to be integrated. One concern in this area is loopback short-circuit behavior preventing proper labeling of the traffic, thereby preventing the clearance from being propagated across such a chain. Disabling of sshd listening on localhost was proposed, but similar concern exists for own address. Requires further investigation and testing.

Proper behavior for ptys was also discussed, including a test case for newrole that allows leakage back to the lower level. The test case should be sent to the list for further discussion of the specifics.

The need for the polyinstantiation mechanism to support copying of a skeleton or base directory when creating member directories was discussed. This needs to be a general hook to support the different ways in which polyinstantiation is applied, as $HOME would have different behavior than /tmp. In addition to initializing the polyinstantiated user home directory, it could also be used to link X-related sockets into the polyinstantiated /tmp.

The approach being taken for labeled printing was described by Matt Anderson. A glue backend has been created between the untrusted cups server and final cups server. A bitmap is sent to the final trusted server, where the banner is applied, eliminating the need to trust the interpreter. Unix domain socket provides labels. At present, the label of the session, not the file, is used, which is correct from a MLS POV but not ideal for MCS or general useability. The file label is not directly visible to the server, so it has to be supplied by the client. A suggestion was made to include both labels in the output as an option, with the file label as "informational", untrustworthy. The patched program needs to be put out for real testing, added to the LSPP repository.

It was noted that the label translation file needs to be protected at system high for LSPP purposes, requiring the introduction of a daemon for translation that can apply permission checks to requests. TCS has such an implementation that they can provide. This would then allow libsetrans to be folded into libselinux since it will just be a client-side communication protocol implementation. The daemon also needs some kind of dominance interface for label comparisons, ideally from the kernel. Requires further discussion on list.

TCS took an action to make their latest versions of policy and device allocator available.

For post-FC5 development, it was suggested that the LSPP developers use FC5 + Steve Grubb's repository for further development since rawhide will not be stable for a little while.

The question of i18n of MLS labels was raised, as well as for MCS. The current infrastructure doesn't specifically try to support it, but it isn't clear where it would break. Kernel would continue to use the primitive s0, c0 syntax that is not language-specific, so this only applies to translated contexts and their handling by applications and by libselinux.

For the audit-by-context patches, the question of how to handle invalid components under current policy was raised again, whether to reject/drop them or retain and later revalidate them upon later policy reload. The decision was to warn-and-retain to ensure that we do not lose audit messages. It would be desirable to be able to flag them as invalid in listings of rules from auditctl.

For ausearch/aureport, it was suggested that context translation for display would be useful as part of the audit record interpretation support. Requires using libsetrans (or libselinux if libsetrans is collapsed into libselinux).

A concern was raised about object reuse / reuse of categories, since they are being translated between human-readable form and the primitive kernel format. This should be covered by audit of changes to setrans.conf, which needs a tool for management.

The approach being proposed by Paul Moore for CIPSO labeling was discussed, also see his WIP slides from the Symposium. He described his NetLabel architecture and usefulness for allowing generalization to RIPSO and CIPSO on IPv6 via destination option. Certain aspects of the proposed implementation were discussed, in particular the need to avoid any blocking from sock_rcv_skb (potentially re-queueing the packet) and the need to catch new server sockets when created via accept. Only significant change is validation on inbound side for CIPSO checking. Initial implementation is only dealing with MLS components and assumes no translation required, will generalize later. Patch targeted for end of March for consideration.

It was asked whether we have sufficient network auditing. As the kernel applies no DAC checking on network IPC and MAC denials are audited by SELinux, the only other area of concern is xinetd, and xinetd restrictions may be outside the scope of the evaluation. Needs further investigation.

There was a general request for more work on unit tests and documentation from the respective upstream projects.