SELinux Symposium

HOME

Participants
FAQ

Symposium Committees

Previous Meetings
2007 Symposium
2006 Symposium
2005 Symposium
2004 Meeting

Sponsors

Sponsorship opportunities

Contact Us

News
Summary of Informal SELinux Meeting Columbia, Maryland, USA, 6 May, 2004
  1. Purpose
An informal meeting involving a group of some of the key contributors to the development of SELinux was held on May 6, 2004, at Tresys Technology, in Columbia, Maryland, USA. A small gathering was initially prompted by Russell Coker's visit to the Washington, D.C. area, but evolved into a larger informal meeting. The purpose of the meeting was to have informal, real-time discussions about the current status, challenges, and future of SELinux.
  1. Attendance
Joshua BrindleHardened Gentoo
David CaplanTresys Technology
Jim ClarkNational Security Agency
Russell CokerRed Hat
Howard HolmNational Security Agency
Jeff JohnsonRed Hat
Peter LoscoccoNational Security Agency
Karl MacMillanTresys Technology
Frank MayerTresys Technology
Stephen SmalleyNational Security Agency
Eamon WalshNational Security Agency

Via conference call:
James MorrisRed Hat
Dan WalshRed Hat
  1. Workshop
There was discussion of whether there was a need for establishing a regular forum, similar in nature to this meeting, aimed at examining the state of SELinux development. Specific issues discussed included the target audience, duration, scheduling, and potential sponsorship of the meetings. Tresys volunteered to organize an initial meeting in the Baltimore/Washington area some time in the fall. It was assumed that this area would accommodate the largest likely user participation. Additionally, there was some discussion as to whether the audience should be limited to core developers or extend to a more general population. The consensus was to model it after the Ottawa Linux kernel conference, which involves an initial meeting of core contributors followed by a more general symposium. The possibility of adding tutorials to this structure was also discussed. Finally, corporate sponsorship and government participation will be investigated.
  1. Fedora Core
A brief update on the status of SELinux and Fedora Core 2 was given. The need for transparency and limited user interaction with SELinux was mentioned as a motivating requirement for much of the work that Red Hat has done. The discussion quickly branched off into details about the policy and policy management as Russell mentioned specific challenges Red Hat had encountered with their integration of SELinux.
  1. Policy
The current state of the public “default” policies was discussed. The set of default policies includes the original example base policy distributed by the NSA, the Fedora core policy, and the recently released targeted (or relaxed) policy. The new targeted policy was written with the aim of isolating a limited set of services or daemons and allowing the rest of the system to be relatively unaffected by the SELinux policy. The purpose of this is to provide an example policy that the general Linux population will be comfortable with (i.e., one that will minimally interfere with their accustomed operations) yet would show how SELinux can provide a level of protection from a service that at some time may be compromised. It makes the initial policy easier to analyze and provides groundwork for slowly introducing increased protection from the policy. Providing the targeted policy as the default might help SELinux gain acceptance, but it is not without potential drawbacks. A possible con to this strategy is that it may make application developers less likely to alter their software to work with SELinux or, where appropriate, be aware of SELinux. This goes against the strong objective to have application developers accept and integrate SELinux controls. Additionally, the targeted policy makes only limited use of the user and role features of SELinux because all users are placed in the same (user_r/user_t) context. It is not clear whether this exposes an area of the policy language that needs additional thought. The desirability of modifying applications to be SELinux aware was discussed. A goal of SELinux is to allow the use of unmodified applications. Certain core system utilities need to be modified to be aware of SELinux (init for example), but in general it is possible to create policies that work with unmodified applications. There was a general consensus that the requirement to modify applications has been a limiting factor to the acceptance of other operating systems with mandatory access controls. This does not mean, however, that it is not desirable to make SELinux specific modifications to certain trusted system services. One example that was mentioned is that it is difficult to create optimal policies for certain types of applications. In particular, the Samba daemon needs the ability to access files with a wide variety of labels in order to service the requests of different users. It is desirable, however, to have SELinux limit the types of files that Samba will access on behalf of a specific user. The standard practices for handling this situation, like executing a separate Samba daemon for each user, will not work in this circumstance because of some details of the SMB/CIFS protocol. It was argued that Samba is a trusted application and it would be appropriate, therefore, to allow it to enforce SELinux access decisions by becoming a user-space object manager. See the “Policy Management” and “Security Enhanced X Status” sections for more details about user-space object managers. The conditional policy features were briefly discussed. It was suggested the conditional policy features could be used to grant privileges to daemons only on startup, similar to a setuid application dropping capabilities. Using the fine-grained labeling of the boolean files in the selinuxfs it is possible for an application to remove access privileges (through setting a boolean) and not have sufficient access privileges to turn them on again. The policy discussion ended with a consensus that it is a mistake to try to overreach on our goals (and likely come up short) on the initial versions of SELinux policies for mainstream users; instead, the initial goal should be to manage expectations of the general community to gain acceptance of type enforcement a little bit at a time.
  1. Policy Management
There was a lengthy discussion on how best to manage policy and the associated file context information. It was clear from the discussion that this is an area that has many unsolved challenges. Though no definitive solutions were determined, several motivating requirements emerged from the discussion and are detailed below.
    1. Local customizations
One of the issues that has arisen as part of the Fedora Core 2 development process is how to handle local customizations to the policy on upgrade. Currently, user modified changes are not overwritten by RPM on upgrade of the policy. Instead the new file is written alongside the locally modified policy file. Users then have to manually merge the changes from the update. This can cause potential problems for large updates. It is possible that the interdependencies with the modified files could create source policies that will not compile if the local customizations prevent the update of one or more files. Gentoo handles this by presenting the user with diffs for all changes to files in /etc. The general consensus was that this is not an appropriate solution for the target audience of Fedora Core.
    1. RPM Integration
There was a lengthy discussion of integration with RPM. RPM is seen as a primary delivery mechanism for policy and file labels. Currently, RPM can record a single label for each file in the package and sets that label at installation time. The policy for each application is not contained with the package that provides that application. Instead, the entire policy is contained in a single RPM. After the previous discussions on default policies, it was clear that RPM needs to support multiple policies and that a single label per file is not sufficient. Several people suggested that modifying RPM to support multiple labels per file would solve this problem. Concerns were voiced about placing multiple labels in each package, however. It was argued that this would enlarge the package size, perhaps substantially, without solving the underlying problem of supporting multiple, arbitrary policies. This problem has some similarities to translation strings in that a potentially large number of translations needs to be provided for each package, they are not necessarily known at package creation time, and it is desirable to upgrade the translations without changing the packages. The translations are supported by allowing RPM to query an external translation database at installation time. There was a consensus that a similar scheme should be adopted by RPM for file labels.
    1. Policy Packaging and Dependencies
There was some discussion about the way policy is currently associated with packages and how the dependency issues are solved. Fedora Core 2 provides a single package with the entire policy for the system. Hardened Gentoo provides a separate package for the policy for each application. The policy packages are automatically installed by marking them as dependencies of the application packages. The Gentoo package management system has a complex infrastructure for optional dependencies to allow the installation of different dependent packages based on user settings or system properties (architecture for example). These optional dependencies allow for considerable flexibility when managing SELinux policy packages.
    1. Binary Policy Modules
The current work by Tresys on developing binary policy modules was discussed. This will allow for the management of policies without source, provide infrastructure and language support for specifying and tracking dependencies, and optionally manage file labeling on the installation and removal of policy modules. Some of the expected benefits of this work would be the looser coupling between portions of the policy and simplified policy management. For example, adding a user to the policy currently requires a full policy development environment including the source for the entire policy. The binary policy modules would allow the addition of a user without source or policy development tools.
    1. The desire to protect certain application by creating a separate domain for each user domain in a system was brought up. This is currently accomplished using macros that will be unavailable in the binary policy modules. It suggested that this could be solved using inheritance. It was agreed to investigate these additional policy language semantics.
    2. User-space Object Managers
      The need for better support of user-space object managers was discussed (see “Security Enhanced X Status” for more discussion). In particular, it was suggested that it is desirable to provide a mechanism that allows the policy for user-space object managers to be selectively separated from each other and the kernel policy. This is access control for policy modification and can be implemented through namespace separation and creating an object abstraction of the policy. Tresys stated that they are starting a research project on this topic which will result in a user-mode policy server based on the binary policy module work.
  1. Security Enhanced X Status
A summary of the work done by the NSA to adapt user space SELinux type controls to X windows was presented. This work involved two main tasks: creating a user-space access vector cache and implementing the object classes and access control within X. The user-space access vector cache has been completed and is available as part of the standard NSA distribution. The implementation is a port of the kernel access vector cache and includes support for flushing on policy reload. The user-space cache is notified of the policy reloads through a netlink socket. The changes required to implement access control for X include the creation of eleven new object classes and modifications to the X server. The new object classes closely mirror those described in the technical report “Securing The X Window System With SELinux” by NAI labs. It was reported that the X developers are enthusiastic about the SELinux work and have accepted the changes to the X server upstream. The modified X server is available from http://www.x.org.
  1. NFS
A report on the progress of integrating SELinux mechanisms into NFS version 3 by the NSA was given. The current implementation was described as relatively simple and experimental. In particular, the implementation does not address many issues and has several assumptions including:
  • the underlying security problems with NFS are not addressed,
  • a secure network is assumed,
  • the client and server must both have the same policy,
  • and the issues with revocation caused by NFS caching are not addressed.
Despite these issues, it is possible to have SELinux access control enforced on NFS mounted file systems. This is done by extending the NFS protocol to handle extended attributes so that a client can retrieve the labels of files of NFS file systems and extending the client to enforce access based on those labels. Additionally, mount options were added to specify that these features should be used. The current implementation is for NFS version 3, but it is expected that in the future work will be done on NFS version 4. It is not clear whether the NFS version 3 implementation will be acceptable upstream, but it is hoped that the future work on NFS version 4 will be. The NFS version 3 patches are available from the NSA website (http://www.nsa.gov/selinux). Finally, it was mentioned that the NFS work has exposed several bugs related to the labeling of sockets created by the kernel. Patches for these problems exist and should be merged soon.
  1. Training and Documentation
It was reported that there has recently been a large amount of new interest expressed from both the corporate and government side for training. Tresys is in the process of refreshing their SELinux course material and will be offering a new set of classes shortly. The NSA is also working on updating past reference papers to reflect the more recent generation of SELinux.
  1. Assurance
Assurance was mentioned several times throughout the symposium. No SELinux system has currently been Common Criteria evaluated at any EAL level, though it is expected that one of the distributions that is currently seeking certification will have a system certified that includes SELinux. SELinux cannot be evaluated separately; only a complete system can be evaluated.
  1. Business Case for SELinux
There was a discussion of strategies for making a case for the use of SELinux to decision makers in organizations. It was argued that making the case to managers can be different than making a case to front-line technical people. It was suggested that the fundamental question that needs to be answered for managers is how does the technology solve an important problem that they have.
©Copyright 2005-2006 SELinux Symposium, LLC
Privacy Statement