Difference between revisions of "Labeled NFS"

From SELinux Wiki
Jump to: navigation, search
(Modified text to reflect new source tree layout)
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
  
Labeled NFS is an effort to provide the mechanisms required to use Mandatory Access Control systems with [http://www.ietf.org/html.charters/nfsv4-charter.html NFSv4]
+
Labeled NFS is an effort to provide the mechanisms required to use Mandatory Access Control systems with [http://www.ietf.org/html.charters/nfsv4-charter.html NFSv4]. If you are interested in participating in the project take a look at the [http://www.selinuxproject.org/page/Labeled_NFS/TODO TODO list].
  
 
== Getting the code ==
 
== Getting the code ==

Revision as of 22:34, 9 December 2009

Introduction

Labeled NFS is an effort to provide the mechanisms required to use Mandatory Access Control systems with NFSv4. If you are interested in participating in the project take a look at the TODO list.

Getting the code

The Labeled NFS prototype is published as a series of public git trees that can be found at http://git.selinuxproject.org/git/.

The Labeled NFS project has recently reorganized the way that patches and source trees are made available. In the past there was one git tree per component and if you wanted to get the patch set for a component you would clone the tree and extract the patches using git-format-patch on the branch containing the patches. This model made development against the tree difficult as it would be destroyed every time it was rebased against upstream losing the history of prior patch versions.

The new method of releasing the Labeled NFS code consists of two git trees. If you look at http://selinuxproject.org/git there is a tree named lnfs-patchset and another named lnfs. The first tree contains a guilt patch series with the Labeled NFS code. As of the moment there is just the version of the patches for 2.6.31 in the tree. As time goes by there will be new commits for the patches which are for newer kernel versions. It is unclear if only release versions will be tracked or if RC tags will be tracked as well. If RC tags are tracked tags rc1 and maybe even rc2 will probably be skipped seeing as rc1 is the close of the merge window and there is no guarantee that the tree is not completely broken.

The second tree mentioned above is the full kernel tree with the Labeled NFS patches applied. While the lnfs-patchset repository uses tags to mark particular kernel versions this isn't possible with the kernel git tree so we use branches instead. In the lnfs tree you will find a branch for each tag in the lnfs-patchset repository. So currently there is a v2.6.31-lnfs branch on the lnfs git tree. If you wish to do development against the LNFS tree or test the code you should check out the latest version of the tree. The main branch for the repository will always be the latest one so a git clone should pull it automatically.

The git trees and which component they contain are listed below

Kernel

  • users/dpquigl/lnfs
  • users/dpquigl/lnfs-patchset

NFS Utils

  • users/dpquigl/nfs-utils
  • users/dpquigl/nfs-utils-patchset

DOI Mapping Framework Library

  • users/dpquigl/libnfsdoimap.git (does not have a corresponding patch tree since it is an original work)

To clone these trees use the command below substituting any of {lnfs, lnfs-patchset, nfs-utils, nfs-utils-patchset, libnfsdoimap.git} for <tree>.

git-clone git://git.selinuxproject.org/~dpquigl/<tree>

Building & Installing the Code

This documentation describes how to build the Labeled NFS kernel and a modified NFS utilities package. The development team uses Fedora as the primary development platform so the instructions below reference Fedora specific utilities and names. If you are running a distro other than Fedora substitute in the appropriate package manager calls and package names for your system.

Installing Development Packages

The nfs-utils git tree requires the development version of several packages to be installed.

yum install tcp_wrappers-devel libevent-devel nfs-utils-lib-devel \
     libgssglue-devel e2fsprogs-devel krb5-devel openldap-devel


Since the Labeled NFS code is published via git and a patch management system named guild the next step is to install these utilities.

yum install git guilt

Labeled-NFS Kernel

This section explains how to clone the Labeled NFS Linux kernel repository and build and install the kernel. If you already know how to build a Linux kernel then you can skip to the section which lists the appropriate kernel config options for the Labeled NFS functionality.

First clone the Labeled-NFS kernel repository.

git clone git://git.selinuxproject.org/~dpquigl/lnfs

This should give you the kernel tree with the latest version branch checked out. You can double check this by issuing the command listed below which should give you a branch based on the latest kernel version.

git-branch
* v2.6.31-lnfs

If instead you see * master then you can issue the following command to checkout and track the lnfs branch.

git-checkout origin/v2.6.31-lnfs -b v2.6.31-lnfs

Once that is done setup the kernel config for the build. A config file with the necessary options can be found at http://www.selinuxproject.org/~dpquigl/files/lnfs/config-2.6.28-rc6. If you prefer to make your own kernel config use the kernel config menu to set the options below. Otherwise copy the config file into your source tree and rename it to .config.

make menuconfig
General setup --->
        [*] Auditing support
Security options --->
        [*] Enable different security models
               [*] Socket and Networking Security Hooks
        [*] NSA SELinux Support
File systems --->
        <*> Ext3 journalling file system support
               [*] Ext3 extended attributes
                       [*] Ext3 Security Labels
        [*] Network File Systems --->
               <*> NFS file system support
                       [*] Provide NFSv4 client support
                               [*] Provide Security Label support for NFSv4 client
               <*> NFS server support
                       [*] Provide NFSv4 server support
                               [*] Provide Security Label support for NFSv4 server

Finally build and install the tree with the commands below and either edit the boot loader to choose the new kernel as the default or select it from the menu on boot.

make
make modules_install install

NFS Utils

This section explains how to build and install the modified NFS Utils package needed to export security labels. This is only needed on the server which is where exportfs does sanity checking on export arguments. If you are deploying this on several systems and have clients that don't intend to export any volumes you don't need to install this package on those clients. However you will still need it on the server.

The First clone the Labeled-NFS nfs-utils repository.

git clone git://git.selinuxproject.org/~dpquigl/nfs-utils

This should give you the source tree with the latest version branch checked out. You can double check this by issuing the command listed below which should give you a branch named the latest version.

git-branch
* <latest-version>

If instead you see * master then you can issue the following command to checkout and track the branch you want.

git-checkout origin/<desired branch> -b <desired branch>

After this build the source tree my issuing the commands below. The final command needs to be executed as root. If you run into any problems when executing the configuration command go back and make sure you have all the necessary development packages installed.

sh autogen.sh
./configure
make
make install

Client & Server Setup

Server

The first thing to do is to make sure that the rpc filesystem is installed and mounted. If you use the default Fedora kernel config this will be the case. There is an issue in that the init scripts for the NFS daemons try to install the sunrpc module and if it can't then it doesn't bother to try mounting the file system. When the NFS modules are built into the kernel modprobe will fail and the file system wont be mounted even though it can be. To check if this is an issue, execute the command below.

# mount | grep rpc_pipefs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

If the output above is missing add the line below to your /etc/fstab file and then run mount -a.

rpc_pipefs      /var/lib/nfs/rpc_pipefs rpc_pipefs      defaults        0 0

After this we need to tell NFSD what to export. Make a directory named /export and then add the line below to your /etc/exports file. Note this is just an example. It is important to make sure that the security_label option is present and that fsid=0. This tells the server that it should export security_labels on this export and that it is also the root of the pseudo file system. for this export.

/export *(rw,fsid=0,sec=unix,security_label,insecure,no_subtree_check,sync)

Next start the NFS service, configure the NFS service to start on several runlevels, and verify the export.

# service nfs start
# chkconfig --level 345 nfs on
# showmount -e

Finally attempt to locally mount the file system and verify that it is using file labels.

# mkdir /mnt/nfsv4
# mount -t nfs4 localhost:/ /mnt/nfsv4
# grep seclabel /proc/mounts

Client

The client setup is much simpler. First enable rpcidmapd with the command below.

# /etc/init.d/rpcidmapd start
# chkconfig --level 345 rpcidmapd on

Then mount the export.

# mkdir /mnt/nfsv4
# mount -t nfs4 server:/ /mnt/nfsv4

If the mount fails check to make sure all the necessary services are running on both ends and that your firewall isn't blocking NFSv4 traffic.

Specification Documents

Mailing Lists

  • IETF NFSv4 Working Group Mailing List: Primary list for discussion for discussion of the NFSv4 standard. This is a moderately high volume list and currently the discussion is centered around preparing NFSv4.1 for final approval.

Presentations

  • MAC resources Posting to the NFSv4 IETF mailing list with pointers to information on Mandatory Access Control (MAC).

News Articles

  • GCN coverage Government Computer News on the project as Dave Q presents at IETF 71.