test

Oracle Solaris Trusted Extensions Administrator's Procedures

Chapter 11 Managing and Mounting Files in Trusted Extensions (Tasks)

This chapter describes how LOFS and NFS mounts work on a system that is configured with Trusted Extensions. This chapter also covers how to back up and restore files.

Sharing and Mounting Files in Trusted Extensions

Trusted Extensions software supports the same file systems and file system management commands as the Solaris OS. Trusted Extensions adds the ability for a non-global zone to share files. In addition, Trusted Extensions attaches a unique label to every non-global zone. All the files and directories that belong to that zone are mounted at the label of the zone. Any shared file systems that belong to other zones or to NFS servers are mounted at the label of the owner. Trusted Extensions prevents any mounts that would violate the mandatory access control (MAC) policies for labeling. For example, a zone's label must dominate all of its mounted file system labels, and only equally labeled file systems can be mounted with read/write permissions.

NFS Mounts in Trusted Extensions

NFS mounts in Trusted Extensions are similar to Solaris mounts. The differences occur in the use of zone root pathnames when mounting a labeled zone in Trusted Extensions, and in the enforcement of MAC policy.

NFS shares in Trusted Extensions are similar to Solaris shares in a global zone. However, the sharing of files from a labeled zone on a multilevel system is unique to Trusted Extensions:

Labels affect which files can be mounted. Files are shared and mounted at a particular label. For a Trusted Extensions client to write to a file that is NFS-mounted, the file must be mounted with read/write permissions and be at the same label as the client. If you are mounting a file between two Trusted Extensions hosts, the server and the client must have compatible remote host templates of type cipso. If you are mounting a file between a Trusted Extensions host and an unlabeled host, files that are at the single label that is specified for the unlabeled host in the tnrhdb file can be mounted. Files that are mounted with LOFS can be viewed, but cannot be modified. For details on NFS mounts, see Access to NFS Mounted Directories in Trusted Extensions.

Labels also affect which directories and files can be viewed. By default, lower-level objects are available in a user's environment. Therefore, in the default configuration, a regular user can view files that are in a zone at a lower level than the user's current level. For example, users can see their lower-level home directories from a higher label. For details, see Home Directory Creation in Trusted Extensions.

If site security forbids the viewing of lower-level objects, you can make lower-level directories invisible to the user. For details, see How to Disable the Mounting of Lower-Level Files.

The mount policy in Trusted Extensions has no MAC overrides. Mounted files that are visible at a lower label can never be modified by a higher-label process. This MAC policy is also in effect in the global zone. A global zone ADMIN_HIGH process cannot modify an NFS-mounted file at a lower label, such as a PUBLIC file or an ADMIN_LOW file. MAC policies enforce the default configuration and are invisible to regular users. Regular users cannot see objects unless they have MAC access to them.

Sharing Files From a Labeled Zone

In the Solaris OS, a non-global zone cannot share directories from its zone. However, in Trusted Extensions, a labeled zone can share directories. The specification of which directories in a labeled zone can be shared is performed in the global zone by using a directory that is outside the root path of the zone. For more discussion, see Global Zone Processes and Labeled Zones.

/zone/labeled-zone/directories

Also called the zone path. Is the path from the global zone to the labeled zone. Every directory under labeled-zone is labeled the same as the zone.

/zone/labeled-zone/root/directories

Also called the zone root path. Is the root path of a labeled zone from the perspective of the global zone. From the perspective of the labeled zone, this is the zone's root, the / directory. This path is not used by the global zone to administer the zone.

To share directories from a labeled zone, the global zone administrator creates and modifies the dfstab file in the /etc directory of the zone path:


/zone/labeled-zone/etc/dfs/dfstab

This /etc directory is not visible from the labeled zone. This directory is distinct from the /etc directory that is visible from the zone:


Global zone view: /zone/labeled-zone/root/etc
Labeled zone view of the same directory: /etc

A dfstab file in this path does not enable labeled directories to be shared.

When the status of the labeled zone is ready or running, the files that are listed in the /zone/labeled-zone/etc/dfs/dfstab file are shared at the label of the zone. For the procedure, see How to Share Directories From a Labeled Zone.

Access to NFS Mounted Directories in Trusted Extensions

By default, NFS-mounted file systems are visible at the label of the exported file system. If the file system is exported with read/write permissions, users at that label can write to the files. NFS mounts that are at a lower label than the user's current session are visible to the user, but cannot be written to. Even if a file system is shared with read/write permissions, the mounting system can write to it only at the label of the mount.

To make lower-level directories that are NFS-mounted visible to users in a higher-level zone, the administrator of the global zone on the NFS server must export the parent directory. The parent directory is exported at its label. On the client side, each zone must have the net_mac_aware privilege. By default, labeled zones include the net_mac_aware privilege in their limitpriv set.

Example 11–1 Providing Access to Lower-Level Home Directories

On the home directory server, the administrator creates and modifies the /zone/labeled-zone/etc/dfs/dfstab file in every labeled zone. The dfstab file exports the /export/home directory with read/write permissions. Thus, when the directory is mounted at the same label, the home directory is writable. To export the /export/home directory of PUBLIC, the administrator creates a workspace at the PUBLIC label on the home directory server, and from the global zone, modifies the /zone/public/etc/dfs/dfstab file.

On the client, the administrator of the global zone checks that every labeled zone, except the lowest label, has the net_mac_aware privilege. This privilege permits the mount. This privilege can be specified by using the zonecfg command during zone configuration. The lower-level home directory can only be viewed. MAC protects the files in the directory from modification.

Home Directory Creation in Trusted Extensions

Home directories are a special case in Trusted Extensions. You need to make sure that the home directories are created in every zone that a user can use. Also, the home directory mount points must be created in the zones on the user's system. For NFS-mounted home directories to work correctly, the conventional location for directories, /export/home, must be used. In Trusted Extensions, the automounter has been modified to handle home directories in every zone, that is, at every label. For details, see Changes to the Automounter in Trusted Extensions.

Home directories are created when users are created. In Trusted Extensions, the Solaris Management Console (Console) is used to create users, so the Console creates the home directories. However, the Console creates the home directories in the global zone of the home directory server. On that server, the directories are mounted by LOFS. Home directories are automatically created by the automounter if they are specified as LOFS mounts.

Note –

When you delete a user by using the Console, only the user's home directory in the global zone is deleted. The user's home directories in the labeled zones are not deleted. You are responsible for archiving and deleting the home directories in the labeled zones. For the procedure, see How to Delete a User Account From a Trusted Extensions System.

However, the automounter cannot automatically create home directories on remote NFS servers. Either the user must first log in to the NFS server or administrative intervention is required. To create home directories for users, see Enable Users to Access Their Home Directories in Trusted Extensions in Oracle Solaris Trusted Extensions Configuration Guide.

Changes to the Automounter in Trusted Extensions

In Trusted Extensions, each label requires a separate home directory mount. The automount command has been modified to handle these labeled automounts. For each zone, the automounter, autofs, mounts an auto_home_zone-name file. For example, the following is the entry for the global zone in the auto_home_global file:


+auto_home_global
*       -fstype=lofs    :/export/home/&

When a zone that permits lower-level zones to be mounted is booted, the following occurs. The home directories of lower-level zones are mounted read only under /zone/<zone-name>/export/home. The auto_home_<zone-name> map specifies the /zone path as the source directory for an lofs remount onto /zone/<zone-name>/home/<username>.

For example, the following is an auto_home_public entry in an auto_home_zone-at-higher-label map that is generated from a higher-level zone:


+auto_home_public
*       -fstype=lofs    :/zone/public/export/home/&

The following is the corresponding entry in the public zone:


auto_home_public
*       -fstype=lofs    :/export/home/&

    When a home directory is referenced and the name does not match any entries in the auto_home_<zone-name> map, the map tries to match this loopback mount specification. The software creates the home directory when the following two conditions are met:

  1. The map finds the match of the loopback mount specification

  2. The home directory name matches a valid user whose home directory does not yet exist in zone-name

For details on changes to the automounter, see the automount(1M) man page.

Trusted Extensions Software and NFS Protocol Versions

In the Solaris 10 11/06 and Solaris 10 8/07 releases, Trusted Extensions recognizes multiple labels on NFS Version 4 (NFSv4) only. Starting in the Solaris 10 5/08 release, Trusted Extensions software recognizes labels on NFS Version 3 (NFSv3) and NFSv4. You can use one of the following sets of mount options:


vers=4 proto=tcp
vers=3 proto=tcp
vers=3 proto=udp

Trusted Extensions has no restrictions on mounts over the tcp protocol. In NFSv3 and NFSv4, the tcp protocol can be used for same-label mounts and for read-down mounts. Read-down mounts require a multilevel port (MLP).

For NFSv3, Trusted Extensions behaves like the Solaris OS. The udp protocol is the default for NFSv3, but udp is used only for the initial mount operation. For subsequent NFS operations, the system uses tcp. Therefore, read-down mounts work for NFSv3 in the default configuration.

In the rare case that you have restricted NFSv3 mounts to use the udp protocol for initial and subsequent NFS operations, you must create an MLP for NFS operations that use the udp protocol. For the procedure, see How to Configure a Multilevel Port for NFSv3 Over udp.

A host that is configured with Trusted Extensions can also share its own file systems with unlabeled hosts. A file or directory that is exported to an unlabeled host is writable if its label equals the label that is associated with the remote host in its trusted networking database entries. A file or directory that is exported to an unlabeled host is readable only if its label is dominated by the label that is associated with the remote host.

Communications with systems that are running a release of Trusted Solaris software is possible only at a single label. The Trusted Extensions system and the Trusted Solaris system must assign to the other system a template with the unlabeled host type. The unlabeled host types must specify the same single label. As an unlabeled NFS client of a Trusted Solaris server, the label of the client cannot be ADMIN_LOW.

The NFS protocol that is used is independent of the local file system's type. Rather, the protocol depends on the type of the sharing computer's operating system. The file system type that is specified to the mount command or in the vfstab file for remote file systems is always NFS.

Backing Up, Sharing, and Mounting Labeled Files (Task Map)

The following task map describes common tasks that are used to back up and restore data from labeled file systems, and to share and mount directories and files that are labeled.

Task 

Description 

For Instructions 

Back up files. 

Protects your data by backing it up. 

How to Back Up Files in Trusted Extensions

Restore data. 

Restores data from a backup. 

How to Restore Files in Trusted Extensions

Share the contents of a directory from a labeled zone. 

Allows the contents of a labeled directory to be shared among users. 

How to Share Directories From a Labeled Zone

Mount the contents of a directory that was shared by a labeled zone. 

Allows the contents of a directory to be mounted in a zone at the same label for read/write. When a higher-level zone mounts the shared directory, the directory is mounted read-only. 

How to NFS Mount Files in a Labeled Zone

Create home directory mount points. 

Creates mount points for every user at every label. This task enables users to access their home directory on a system that is not the NFS home directory server. 

Enable Users to Access Their Home Directories in Trusted Extensions in Oracle Solaris Trusted Extensions Configuration Guide

Hide lower-level information from a user who is working at a higher label. 

Prevent the viewing of lower-level information from a higher-level window. 

How to Disable the Mounting of Lower-Level Files

Troubleshoot file system mounting problems. 

Resolve problems with mounting a file system. 

How to Troubleshoot Mount Failures in Trusted Extensions

ProcedureHow to Back Up Files in Trusted Extensions

  1. Assume the Operator role.

    This role includes the Media Backup rights profile.

  2. Use one of the following backup methods:

    • /usr/lib/fs/ufs/ufsdump for major backups

    • /usr/sbin/tar cT for small backups

    • A script calling either of these commands

      For example, the Budtool backup application calls the ufsdump command. See the ufsdump(1M) man page. For details on the T option to the tar command, see the tar(1) man page.

ProcedureHow to Restore Files in Trusted Extensions

  1. Assume the System Administrator role.

    This role includes the Media Restore rights profile.

  2. Use one of the following methods:

    • /usr/lib/fs/ufs/ufsrestore for major restores

    • /usr/sbin/tar xT for small restores

    • A script calling either of these commands

    For details on the T option to the tar command, see the tar(1) man page.

    Caution – Caution –

    Only these commands preserve labels.

ProcedureHow to Share Directories From a Labeled Zone

As in the Solaris OS, the Mounts and Shares tool in the Solaris Management Console is used to share and mount files from the global zone. The tool cannot be used to mount or share directories that originate in labeled zones. Create a dfstab file at the label of the zone, and then restart the zone to share the labeled directories.

Caution – Caution –

Do not use proprietary names for shared file systems. The names of shared file systems are visible to every user.

Before You Begin

You must be superuser, or in the System Administrator role in the global zone on the file server.

  1. Create a workspace at the label of the directory that is going to be shared.

    For details, see How to Add a Workspace at a Particular Label in Oracle Solaris Trusted Extensions User’s Guide.

  2. Create a dfstab file in at the label of that zone.

    For each zone that will share a directory, repeat the following steps:

    1. Create the /etc/dfs directory in the zone.


      # mkdir -p /zone/zone-name/etc/dfs

    2. Open the trusted editor.

      For details, see How to Edit Administrative Files in Trusted Extensions.

    3. Type the full pathname of the dfstab file into the editor.


      # /zone/zone-name/etc/dfs/dfstab

    4. Add an entry to share a directory from that zone.

      The entry describes the directory from the perspective of the zone root path. For example, the following entry shares an application's files at the label of the containing zone:


      share -F nfs -o ro /viewdir/viewfiles

  3. For each zone, share the directories by starting the zone.

    In the global zone, run one of the following commands for each zone. Each zone can share its directories in any of these ways. The actual sharing occurs when each zone is brought into the ready or running state.

    • If the zone is not in the running state and you do not want users to log in to the server at the label of the zone, set the zone state to ready.


      # zoneadm -z zone-name ready

    • If the zone is not in the running state and users are allowed to log in to the server at the label of the zone, boot the zone.


      # zoneadm -z zone-name boot

    • If the zone is already running, reboot the zone.


      # zoneadm -z zone-name reboot

  4. Display the directories that are shared from your system.


    # showmount -e

  5. To enable the client to mount the exported files, see How to NFS Mount Files in a Labeled Zone.

Example 11–2 Sharing the /export/share Directory at the PUBLIC Label

For applications that run at the label PUBLIC, the system administrator enables users to read the documentation in the /export/share directory of the public zone. The zone named public runs at the label PUBLIC.

First, the administrator creates a public workspace and edits the dfstab file.


# mkdir -p /zone/public/etc/dfs
# /usr/dt/bin/trusted_edit /zone/public/etc/dfs/dfstab

In the file, the administrator adds the following entry:


## Sharing PUBLIC user manuals
share -F nfs -o ro /export/appdocs

The administrator leaves the public workspace and returns to the Trusted Path workspace. Because users are not allowed to log in to this system, the administrator shares the files by putting the zone in the ready state:


# zoneadm -z public ready

Users can access the shared directories once the directories are mounted on the users' systems.

ProcedureHow to NFS Mount Files in a Labeled Zone

In Trusted Extensions, a labeled zone manages the mounting of files in its zone.

Files from unlabeled and labeled hosts can be mounted on a Trusted Extensions labeled host.

Trusted Extensions uses the same mounting interfaces as the Solaris OS:

Before You Begin

You must be on the client system, in the zone at the label of the files that you want to mount. Unless you are using the automounter, you must be superuser, or be in the System Administrator role. To mount from lower-level servers, the zone must be configured with the net_mac_aware privilege.

  1. To NFS mount files in a labeled zone, use the following procedures.

    Most procedures include creating a workspace at a particular label. To create a workspace, see How to Add a Workspace at a Particular Label in Oracle Solaris Trusted Extensions User’s Guide.

    • Mount files dynamically.

      In the labeled zone, use the mount command. For an example of mounting files dynamically, see Example 11–3.

    • Mount files when the zone boots

      In the labeled zone, add the mounts to the vfstab file.

      For examples of mounting files when a labeled zone boots, see Example 11–4 and Example 11–5.

    • Mount home directories for systems that are administered with LDAP.

      1. At every label, add the user specifications to the auto_home_zone-name files.

      2. Then, use these files to populate the auto_home_zone-name database on the LDAP server.

      For an example, see Example 11–6.

    • Mount home directories for systems that are administered with files.

      1. Create and populate an /export/home/auto_home_lowest-labeled-zone-name file.

      2. Edit the /etc/auto_home_lowest-labeled-zone-name file to point to the newly populated file.

      3. Modify the /etc/auto_home_lowest-labeled-zone-name file in every higher-level zone to point to the file that you created in Step a.

      For an example, see Example 11–7.

Example 11–3 Mounting Files in a Labeled Zone by Using the mount Command

In this example, the system administrator mounts a remote file system from a public zone. The public zone is on a multilevel server.

After assuming the System Administrator role, the administrator creates a workspace at the label PUBLIC. In that workspace, the administrator runs the mount command.


# zonename
public
# mount -F nfs remote-sys:/zone/public/root/opt/docs  /opt/docs

A single-label file server at the label PUBLIC also contains documents to be mounted:


# mount -F nfs public-sys:/publicdocs  /opt/publicdocs

When the public zone of the remote-sys file server is in the ready or running state, the remote-sys files successfully mount on this system. When the public-sys file server is running, the files successfully mount.

Example 11–4 Mounting Files Read/Write in a Labeled Zone by Modifying the vfstab File

In this example, the system administrator mounts two remote file systems at the label PUBLIC in the local system's public zone when the public zone boots. One file system mount is from a multilevel system, and one file system mount is from a single-label system.

After assuming the System Administrator role, the administrator creates a workspace at the label PUBLIC. In that workspace, the administrator modifies the vfstab file in that zone.


## Writable books directories at PUBLIC
remote-sys:/zone/public/root/opt/docs  - /opt/docs  nfs  no  yes  rw
public-sys:/publicdocs    - /opt/publicdocs  nfs no yes rw

To access the files in the remote labeled zone of the multilevel system, the vfstab entry uses the zone root path of the remote system's public zone, /zone/public/root, as the directory pathname to the directories to mount. The path to the single-label system is identical to the path that would be used on a Solaris system.

In a terminal window at the label PUBLIC, the administrator mounts the files.


# mountall
Example 11–5 Mounting Lower-Level Files in a Labeled Zone by Modifying the vfstab File

In this example, the system administrator mounts a remote file system from a public zone in the local system's internal zone. After assuming the System Administrator role, the administrator creates a workspace at the label INTERNAL, then modifies the vfstab file in that zone.


## Readable books directory at PUBLIC
## ro entry indicates that PUBLIC docs can never be mounted rw in internal zone
remote-sys:/zone/public/root/opt/docs  - /opt/docs  nfs  no  yes  ro

To access the files in the remote labeled zone, the vfstab entry uses the zone root path of the remote system's public zone, /zone/public/root, as the directory pathname to the directories to mount.

From the perspective of a user in the internal zone, the files can be accessed at /opt/docs.

In a terminal window at the label INTERNAL, the administrator mounts the files.


# mountall
Example 11–6 Mounting Labeled Home Directories in a Network That Is Administered by Using LDAP

In this example, the system administrator enables a new user, ikuk, to access her home directory at every label. This site uses two home directory servers, and is administered by using LDAP. The second server contains the home directories for the users jdoe and pkai. The new user is added to this list.

First, after assuming the System Administrator role, the administrator modifies the auto_home_zone-name files in the /etc directory of the global zone to include the new user on the second home directory server.


## auto_home_global file
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk   homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&
 

## auto_home_internal file
## Mount the home directory from the internal zone of the NFS server
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk   homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&
 

## auto_home_public
## Mount the home directory from the public zone of the NFS server
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk   homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

Next, to enable the users to log in at all labels, the administrator repeats these edits for the auto_home_zone-name files at every label.

Finally, after modifying every auto_home_zone-name file on this system, the administrator uses these files to add entries to the LDAP database.

Similar to the Solaris OS, the +auto_home_public entry in the /etc/auto_home_zone-name files directs the automounter to the LDAP entries. The auto_home_zone-name files on other systems on the network are updated from the LDAP database.

Example 11–7 Mounting a Lower-Level Home Directory on a System That Is Administered by Using Files

In this example, the system administrator enables users to access their home directories at every label. The labels at the site are PUBLIC, INTERNAL, and NEEDTOKNOW. This site uses two home directory servers, and is administered by using files. The second server contains the home directories for the users jdoe and pkai.

To accomplish this task, the system administrator defines the public zone NFS home directories in the public zone, and shares this configuration with the internal and needtoknow zones.

First, after assuming the System Administrator role, the administrator creates a workspace at the label PUBLIC. In this workspace, the administrator creates a new file, /export/home/auto_home_public. This file contains all the customized per-user NFS specification entries.


## /export/home/auto_home_public file at PUBLIC label
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
*      homedir-server:/export/home/&

Second, the administrator modifies the /etc/auto_home_public file to point to this new file.


## /etc/auto_home_public file in the public zone
## Use /export/home/auto_home_public for the user entries
## +auto_home_public
+ /export/home/auto_home_public

This entry directs the automounter to use the contents of the local file.

Third, the administrator similarly modifies the /etc/auto_home_public file in the internal and needtoknow zones. The administrator uses the pathname to the public zone that is visible to the internal and needtoknow zones.


## /etc/auto_home_public file in the internal zone
## Use /zone/public/export/home/auto_home_public for PUBLIC user home dirs
## +auto_home_public
+ /zone/public/export/home/auto_home_public


## /etc/auto_home_public file in the needtoknow zone
## Use /zone/public/export/home/auto_home_public for PUBLIC user home dirs
## +auto_home_public
+ /zone/public/export/home/auto_home_public

When the administrator adds the new user ikuk, the addition is made to the /export/home/auto_home_public file at the PUBLIC label.


## /export/home/auto_home_public file at PUBLIC label
jdoe   homedir2-server:/export/home/jdoe
pkai   homedir2-server:/export/home/pkai
ikuk   homedir2-server:/export/home/ikuk
*      homedir-server:/export/home/&

The higher-level zones read down to obtain the per-user home directories from the lower-level public zone.

ProcedureHow to Troubleshoot Mount Failures in Trusted Extensions

Before You Begin

You must be in the zone at the label of the files that you want to mount. You must be the superuser, or in the System Administrator role.

  1. Check the security attributes of the NFS server.

    Use the Security Templates tool in the Solaris Management Console at the appropriate scope. For details, see Initialize the Solaris Management Console Server in Trusted Extensions in Oracle Solaris Trusted Extensions Configuration Guide.

    1. Verify that the IP address of the NFS server is an assigned host in one of the security templates.

      The address might be directly assigned, or indirectly assigned through a wildcard mechanism. The address can be in a labeled template, or in an unlabeled template.

    2. Check the label that the template assigns to the NFS server.

      The label must be consistent with the label at which you are trying to mount the files.

  2. Check the label of the current zone.

    If the label is higher than the label of the mounted file system, then you cannot write to the mount even if the remote file system is exported with read/write permissions. You can only write to the mounted file system at the label of the mount.

  3. To mount file systems from an NFS server that is running earlier versions of Trusted Solaris software, do the following:

    • For a Trusted Solaris 1 NFS server, use the vers=2 and proto=udp options to the mount command.

    • For a Trusted Solaris 2.5.1 NFS server, use the vers=2 and proto=udp options to the mount command.

    • For a Trusted Solaris 8 NFS server, use the vers=3 and proto=udp options to the mount command.

    To mount file systems from any of these servers, the server must be assigned to an unlabeled template.