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.
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 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:
Shares and mounts in the global zone – Sharing and mounting files in the global zone of a Trusted Extensions system is almost identical to the procedure in the Solaris OS. For mounting files, the automounter, the vfstab file, and the mount command can be used. For sharing files, the dfstab file is used.
Mounts in labeled zones – Mounting files in labeled zones in Trusted Extensions is almost identical to mounting files in non-global zones in the Solaris OS. For mounting files, the automounter, the vfstab file, and the mount command can be used. In Trusted Extensions, a unique automount_home_label configuration file exists for each labeled zone.
Shares in labeled zones – Files in a labeled zone can be shared at the label of the zone by using a dfstab file that is at the label of the zone, but is visible to the global zone only. So, configuring a labeled zone to share files is performed by the global zone administrator in the global zone. This configuration file is not visible from its labeled zone. For more discussion, see Global Zone Processes and Labeled Zones.
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.
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.
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.
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.
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.
Server configuration – On the NFS server, you export the parent directory in a dfstab file. If the parent directory is in a labeled zone, the dfstab file must be modified in the labeled zone of the parent directory. The dfstab file for a labeled zone is visible only from the global zone. For the procedure, see How to Share Directories From a Labeled Zone.
Client configuration – The net_mac_aware privilege must be specified in the zone configuration file that is used during initial zone configuration. So, a user who is permitted to view all lower-level home directories must have the net_mac_aware privilege in every zone, except the lowest zone. For an example, see How to NFS Mount Files in a Labeled Zone.
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 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.
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.
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:
The map finds the match of the loopback mount specification
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.
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.
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. | |
Restore data. |
Restores data from a backup. | |
Share the contents of a directory from a labeled zone. |
Allows the contents of a labeled directory to be shared among users. | |
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. | |
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. | |
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. | |
Troubleshoot file system mounting problems. |
Resolve problems with mounting a file system. |
Assume the Operator role.
This role includes the Media Backup rights profile.
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.
Assume the System Administrator role.
This role includes the Media Restore rights profile.
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.
Only these commands preserve labels.
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.
Do not use proprietary names for shared file systems. The names of shared file systems are visible to every user.
You must be superuser, or in the System Administrator role in the global zone on the file server.
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.
Create a dfstab file in at the label of that zone.
For each zone that will share a directory, repeat the following steps:
Create the /etc/dfs directory in the zone.
# mkdir -p /zone/zone-name/etc/dfs |
Open the trusted editor.
For details, see How to Edit Administrative Files in Trusted Extensions.
Type the full pathname of the dfstab file into the editor.
# /zone/zone-name/etc/dfs/dfstab |
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 |
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 |
Display the directories that are shared from your system.
# showmount -e |
To enable the client to mount the exported files, see How to NFS Mount Files in a Labeled Zone.
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.
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.
To mount the files read/write from a single-label host, the assigned label of the remote host must be identical to the zone in which the file is being mounted.
Files that are mounted by a higher-level zone are read-only.
In Trusted Extensions, the auto_home configuration file is customized per zone. The file is named by zone name. For example, a system with a global zone and a public zone has two auto_home files, auto_home_global and auto_home_public.
Trusted Extensions uses the same mounting interfaces as the Solaris OS:
To mount files at boot, use the /etc/vfstab file in the labeled zone.
To mount files dynamically, use the mount command in the labeled zone.
To automount home directories, use the auto_home_zone-name files.
To automount other directories, use the standard automount maps. If the automount maps are in LDAP, use LDAP commands to manage them.
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.
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.
At every label, add the user specifications to the auto_home_zone-name files.
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.
Create and populate an /export/home/auto_home_lowest-labeled-zone-name file.
Edit the /etc/auto_home_lowest-labeled-zone-name file to point to the newly populated file.
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.
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.
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 |
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 |
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.
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.
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.
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.
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.
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.
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.
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.