Chapter 9 Managing Files and File Systems

This chapter describes how to manage files, directories, and file systems and how to share and mount files in the Trusted Solaris environment. This chapter contains the following procedures:

• "To Back Up Files "

• "To Restore Files"

• "To Change Labels and Privileges With the File Manager"

• "To Set Security Attributes While Creating a Local File System"

• "To Set Security Attributes on a File System "

• "To Specify Mount-time Security Attributes on the Command Line"

• "To Specify Mount-time Security Attributes in the vfstab_adjunct File"

• "To Share a Directory"

• "To Mount a TMPFS File System Using the Command Line "

• "To Mount a CD-ROM with a HSFS File System"

• "To Automatically Launch a CD Player for an Audio CD-ROM"

• "To Listen to an Audio CD as any User or Role"

• "To Troubleshoot Mount Failures"

Requirements Unique to Trusted Solaris File Systems

The Trusted Solaris operating environment supports the same files and directories, most of the file system types, and all of the file system management commands in the Solaris operating environment. The Trusted Solaris environment adds security attributes. Whenever a file or directory is accessed, Solaris and Trusted Solaris security attributes are checked for access decisions. The Trusted Solaris environment provides the following features and constraints on files and file systems:

• No order requirements are imposed on the labels of directories in a pathname.

• Files and directories can be created only at the same label as the containing directory.

• Privileged subjects can create files and directories and relabel existing files and directories at any valid label to create upgraded or downgraded objects.

  See "To Change Labels and Privileges With the File Manager".

• The system can be configured to show the names of upgraded files and directories. By default, their names are not visible.

  To make the names are visible, the Security Administrator role changes the setting of the tsol_hide_upgraded_names switch in the /etc/system file as described in "To Change Configurable Kernel Switch Settings".

• Directory names are cleared when a directory is removed. Clearing the names meets the object reuse requirement that the names of removed directories should no longer be accessible.

• Trusted Solaris symbolic links have labels.

• Multilevel directories (MLDs) appear in the file system as ordinary directories with a flag identifying them as MLDs.

• MLDs require no privilege to create, delete, or use.

• Read-down access to single-label directories (SLD)s within an MLD permits an unprivileged process to combine information from SLDs at its own and lower labels.

• If an MLD is mounted by a single-label computer, an SLD is mounted. The SLD corresponds to the label administratively assigned to the single-label computer in the trusted networking databases.

  If, for example, a user's home directory is automounted on an unlabeled computer, only the SLD with the default label assigned to the computer in the Security Families template is mounted. For example, if the default label for the computer is INTERNAL_USE_ONLY, then only the SLD at INTERNAL_USE_ONLY is mounted on the unlabeled computer.

Specifying Security Attributes on Files and File Systems

Security attributes can be specified at the level of an individual file or directory, or at the level of the file system.

If a needed attribute is not obtained elsewhere, a set of defaults is used. For rules about how attributes are obtained, see "Trusted Solaris Attribute Precedence Rules".

Security Attributes on Files and Directories

The following attributes are present on objects in Solaris and Trusted Solaris file systems: User Id, Group Id, Permission Mode, and Access ACL (optional). Trusted Solaris files and directories have additional security attributes. The following table describes the extended security attributes provided in Trusted Solaris software.

Specifying Security Attributes on Files and Directories

The Trusted Solaris File Manager enables users and administrators to change permissions on files and directories. It also enables authorized users and administrators to set privileges and labels on files and directories. Authorizations are required to change privileges and labels. Additional authorizations are required when the change is outside DAC or MAC policy.

Changing Labels and Privileges

The File Manager Selected menu has a Change Labels option to set the label. A user or role that has the setlabel(1) command in one of its profiles can also change labels. The File Manager Selected menu also has a Change Privileges option to set forced and allowed privileges on executable files. Changing forced and allowed privileges can also be done on the command line by any account that has the setfpriv(1) command in one of its profiles.

The following authorizations are required in order to set privileges and labels through the File Manager Selected menu options:

• Setting privileges requires the Set File Privileges authorization.

• Upgrading file and directory labels requires the Upgrade File Label authorization.

• Downgrading file and directory labels requires the Downgrade File Label authorization.

The following figure shows the File Manager Selected menu when the account has the required authorizations. See "To Change Labels and Privileges With the File Manager" for how to change labels and privileges.

Figure 9-1 File Manager Selected Menu for an Authorized User

Changing File and Directory Attribute Flags

The getfattrflag(1) command gets the security attribute flags of a file or directory and the setfattrflag(1) command sets the public object flag on a file and sets the MLD flag on a directory.

Security Attributes on File Systems

File systems supported by Trusted Solaris software are characterized by whether their attributes can be changed or not. When the attributes can be changed, they are called variable attribute or variable file systems. File systems that do not support Trusted Solaris extended security attributes are called fixed because any attributes assigned to them (either at mount time or by default) cannot be altered.

Following are more details relevant for understanding and managing the various types of variable and fixed file system types:

• All ufs-type file systems are variable and therefore, all file systems installed with the Trusted Solaris software are variable.

  For example, if you connect a hard disk containing an unlabeled file system directly to a Trusted Solaris computer, when the file system is ufs-mounted the unlabeled file system becomes a variable file system, with a default set of attributes shown in Table 9-2.

• An nfs-type file system mounted from a Trusted Solaris or TSIX NFS server is variable.

• An nfs-type file system mounted from an NFS server running another operating environment is fixed.

• tmpfs file systems are variable.

• These file system types are always fixed: fdfs, hsfs, pcfs.

• The lofs-type file system's attributes are those of the underlying file system. See "Mounting File Systems in the Trusted Solaris Environment" for more information.

The following table shows the security attributes for variable-attribute file systems, with the default values that are used when none are specified.

The Label Attribute

In variable file systems the label of each object is set when it is created and can be changed by an authorized user. In fixed file systems, a single label is assigned when the file system is mounted. The label can be changed only if an object is moved from the fixed file system. Because they are configured to have a single label when mounted on Trusted Solaris hosts, fixed attribute file systems are also referred to as single-label file systems.

The label is obtained differently when a fixed-attribute file system is NFS-mounted than when it is PCFS-mounted from a floppy disk or HSFS-mounted from a CDROM.

• An NFS-mounted file system is assigned the label that is specified in the Default Label setting in the Security Families template assigned to the remote computer from which the file system is NFS-mounted.

• For a PCFS- or HSFS-mounted fixed-attribute file system, the label is specified at mount time. either on the mount command line or in an entry in the vfstab_adjunct(4) file.

Specifying Security Attributes on Variable File Systems

(See "To Set Security Attributes on a File System ". The Security Administrator role uses the getfsattr(1M) command to get the security attributes of a file system. The setfsattr(1M) command tunes the attributes set on an already-existing file system ).

Do not change or explicitly set the security attributes of the /, /usr, or /var file systems on a Trusted Solaris host. The results are unpredictable.

Specifying Security Attributes on Fixed File Systems

When mounting a fixed-attribute file system, the Security Administrator role can specify security attributes on the command line with the mount(1M) command, in the vfstab_adjunct(4) file, or in the /etc/auto_master file other autofs maps (see automount(1M)).

In the mount command, most of the keyword=value pairs used to specify security attributes with the -S can be specified with the -o option. If a keyword is followed by multiple values separated by commas, the keyword must be specified with the-S option becauses comma-separated values are not allowed after -o. Use of the -o option is preferable. For more about the security-related mount options that can be specified with the -o option, see "Mount Options Used for Protection ".

Any attributes specified at mount time are applied to all the files and directories in the mounted file system, if the files or directories themselves do not have the attribute. Any attributes on the file or directory are used. If the file or directory does not have an attribute and none is specified at mount-time, the defaults shown in Table 9-3 apply.

In fixed attribute file systems, the security attributes cannot change on an object as long as the object resides in the file system.

If, for example, the mounted file system /spare contains a file called test, no one can change the label of /spare/test. However, if /spare/test is copied into another directory such as /tmp or /export/home/secadmin, its label can be changed.

The following table shows the attributes that can be specified for a fixed attribute file system when the file system does not support the attribute, and the default vales that apply if no value for the attribute is supplied.

The following example shows a command line to NFS-mount a fixed attribute file system called /spare from an NFS server running the Solaris operating environment. The server is called outside. /spare is mounted with a label of INTERNAL_USE_ONLY using mount with the -S option on the command line as shown here:

$ mount -F nfs -S "slabel=INTERNAL_USE_ONLY" outside:/spare /spare

Mounting File Systems in the Trusted Solaris Environment

The Trusted Solaris mount(1M) command can be used to mount the types of file systems shown in the following table.

The table includes cross-references to mount_* mount man pages, when they are available for the named filesystem type, such as mount_nfs(1M) and mount_ufs(1M). The mount man page describes security attributes that can be set for any file system type that supports using the -S option at mount time and describes the privileges, UID and GID that mount needs in order to succeed. The mount_* man pages give the subcommands that can be entered with the -o option for each filesystem type. See also "Security Attributes on File Systems" and following for more about security attributes.

The CACHEFS file system type is not supported.

Mount Options Used for Protection

The mount(1M) command can be used with the -o option followed by one of four protection options. The options are also valid in the vfstab(4) file. Some options can be used to protect the data on the file system being mounted, while others prevent a Trojan Horse attack initiated from the mounted file system. The mount restrictions shown in the following table are supported on all file system types. The Default Values column shows the values used when no option is specified.

The ro and suid options to disallow writes and ignore set user ID bits are available in the Solaris version of the mount command.

Summary of Attributes on Various File System Types

The following table indicates how different file systems support the various file system attributes. See the key in Table 9-7.

MLDs are supported only by the following file system types:

• ufs (always variable)

• nfs-variable

  (NFS file systems mounted from Trusted Solaris servers)

• lofs, and

• tmpfs

Trusted Solaris Attribute Precedence Rules

A file or directory's attributes take precedence over the attributes on the containing file system. Attributes specified at mount-time take precedence over filesystem attributes already in effect for a file system. Any attributes not obtainable at mount time or from the file system are assigned from the defaults.

The following figure illustrates the precedence rules.

Figure 9-2 Trusted Solaris Attribute Precedence Rules

Trusted Solaris Software and NFS

Trusted Solaris software supports both NFS protocols supported in the Solaris operating environment and the Trusted Solaris 1.x release: NFS Version 2 (V2) and NFS Version 3 (V3) .

When a Solaris computer shares a file system using one of the NFS protocols above, the administrator of a computer running one of the following Trusted Solaris releases: 2.5.1, 7, 8, or 8 4/01, can specify the corresponding NFS protocol version to access the file system at a single label.

A Trusted Solaris computer can also specify the appropriate NFS protocol to share its own file systems with unlabeled client computers. A file or directory exported to an unlabeled client is writable if its label equals the label associated with the client computer in its trusted networking database entries. A file or directory exported to an unlabeled client is readable only if its label is dominated by the label associated with the client computer.

Communications with computers running Trusted Solaris 1.1 and 1.2 releases is possible only at a single label. Both systems must assign each other a template with the unlabeled host type specified with the same single label.

Any file system being mounted from a NFS server running the Trusted Solaris environment must be mounted with vers=2 and proto=udp mount options.

The NFS protocol used (whether it is NFS V2/V3, TNFS, TSIG/TNFS) is independent of the type of the local file system. Rather, the protocol depends on the type of the exporting computer's operating system. The file system type specified to the mount command or in the vfstab for remote file systems is always nfs.

Sharing Directories

Sharing directories for mounting by other computers works in the Trusted Solaris environment as it does in the Solaris environment. Trusted Solaris solftware provides two new Trusted Solaris mount options nodevices and nopriv to limit device use and privilege use. See "To Share a Directory".

Troubleshooting Mount Failures

If an attempted mount fails, and if all the standard setup has been done as required in the base Solaris system (as described in "Mounting and Unmounting File Systems (Tasks)" in System Administration Guide, Volume 1), do the steps in "To Troubleshoot Mount Failures".

Managing Files and File Systems (Tasks)

To Back Up Files

1. Assume the Operator role or another role with the Media Backup rights profile.

2. Use one of the following backup methods:

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

   • /usr/sbin/tar -T with other options for small backups

   • A script calling either of the above commands

     For example, the Budtool backup application calls the ufsdump command.

Only these commands preserve security attributes and can read multilevel and single-level directories correctly.

To Restore Files

1. Assume the System Administrator role or any other role with the Media Restore rights profile.

2. Use one of the following methods:

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

   • /usr/sbin/tar -T with other options for small restores

   • A script calling either of the above commands, such as Budtool.

Only these commands preserve security attributes and can restore multilevel and single-level directories correctly.

To Change Labels and Privileges With the File Manager

1. Assume the Security Administrator role and go to or create a workspace at the appropriate label.

2. Bring up the File Manager, navigate to the directory, and highlight the file whose privileges or label you wish to change.

3. To change privileges, choose Privileges from the Selected menu.

   The File Manager Privileges dialog box displays as shown below.

   

   1. On the File Manager Privileges dialog box, click the button for Allowed, and move the desired privileges from the Excluded to the Included list.

   2. Click OK, and repeat the above step for Forced Privileges.

   3. Click OK.

4. To change labels, choose Labels from the Selected menu.

   The File Manager Label Builder displays.

   

5. Enter a label by typing a label in the Update With field, or by clicking the desired label components.

6. Click OK.

To Set Security Attributes While Creating a Local File System

1. Assume the System Administrator role and go to an ADMIN_HIGH workspace.

   See "To Work at a Different Label", if needed.

2. Using the File Manager or the mkdir command, make the mount point directory.

   $ mkdir /newpublic

3. Use the Set Mount Points Action to edit the /etc/vfstab file with the following entry:

   /dev/dsk/c0t3d0s3 /dev/rdsk/c0t3d0s3 /newpublic ufs 2 yes -

4. Write and quit the file.

5. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

6. Execute the newsecfs command with the options that specify the desired alternative security attributes, then mount the file system.

   The following example sets a label range of SECRET to SECRET.

   $ newsecfs -l "Secret;Secret" /newpublic $ mount /spublic

   See the newsecfs(1M) man page for details.

To Set Security Attributes on a File System

1. Assume the System Administrator role and go to an ADMIN_LOW workspace.

2. Use the Set Mount Points action to open the /etc/vfstab file and make sure that an entry exists for the file system:

   /dev/dsk/c0t3d0s4 /dev/rdsk/c0t3d0s4 /spublic ufs 2 yes -

3. Change to an ADMIN_HIGH workspace.

   See "To Work at a Different Label" for changing the label of your workspace.

4. Enter the umount command to unmount the file system.

   $ umount /spublic

5. Assume the Security Administrator role and go to an ADMIN_LOW workspace.

6. Enter the setfsattr command with the appropriate arguments, then remount the file system.

   The following example sets a label range of SECRET to SECRET.

   $ setfsattr -l "Secret;Secret" /public $ mount /spublic

   ---

   Caution -

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

   ---

To Specify Mount-time Security Attributes on the Command Line

The following procedure mounts a tmpfs-type file system, swap, on /mnt with all allowed and all forced privileges.

1. Assume the System Administrator role and go to an ADMIN_LOW workspace.

2. Enter the mount command, using the -S option followed by any security attributes that you wish to specify.

   $ mount -F tmpfs -S "allowed=all;forced=all" swap /mnt

To Specify Mount-time Security Attributes in the vfstab_adjunct File

1. Assume the administrator role and go to an ADMIN_HIGH workspace.

   See "To Log In and Assume a Role", if needed.

2. Use the Set Mount Points action to open the vfstab(4) file for editing.

3. Specify the mount point as described in the vfstab man page and add filesystem-specific security options in the mount options column as desired.

   See the filesystem-specific options in the mount_* man page for the file system type.

   The example below shows a filesystem type of ufs, mounted with the Trusted Solaris nodevices and nopriv mount options and the Solaris nosuid mount option.

   /dev/dsk/c0t3d0s4 /dev/rdsk/c0t3d0s4 /spublic ufs 2 yes nodevices,nopriv,nosuid

4. Save and close the file.

   :wq

5. Assume the Security Administrator role and go to an ADMIN_HIGH workspace.

6. Use the Set Mount Attributes action to open the vfstab_adjunct(4) file for editing.

7. Copy and paste the template entry at the top of the file, and modify the copy.

   #<mount point>; \ #slabel=; \ #forced=; allowed=; \ #low_range=; hi_range=; \ #mld_prefix=;

   The example below gives the following security attributes to /spublic: all files in the file system get an slabel (label) of SECRET A, all allowed privileges, and all the file-related privileges.

   # Assigns the Secret A label and label range, all file-related # forced privileges and all allowed privileges to an unlabeled file system # /spublic;\ slabel="Secret A";\ forced=file_audit,file_chown,file_dac_execute,file_dac_read,\ file_dac_search,file_dac_write,file_downgrade_sl,file_lock,\ file_mac_read,file_mac_search,file_mac_write,file_owner,file_setdac,\ file_setid,file_setpriv,file_upgrade_sl;\ allowed=all;\ low_range="Secret A";\ hi_range="Secret A";

8. Save and close the file.

   :wq

To Share a Directory

1. Assume the System Administrator role in an ADMIN_LOW workspace and invoke the Solaris Management Console.

2. Under Trusted Solaris Management Console, click this-host: Scope=Files, Policy=TSOL, then Storage. Provide a password when prompted.

3. Double-click Mounts and Shares, double-click Share, then choose Add Shared Directory from the Action menu.

4. Enter the file system you want to share.

5. After adding the directory, modify its attributes by double-clicking it, then modifying its properties.

   Refer to the online help to guide you.

   The following dfstab entry shares a book directory with the nodevices, nopriv, nosuid, and rw options.

   share -F nfs -o nodevices,nopriv,nosuid,rw -d "Books" /spare/books

6. Click OK when done.

   The tool modifies the dfstab(4) file, runs the shareall(1M) command, and starts the NFS daemon.

7. To confirm that the file system is shared, enter the share(1M) command with no options.

   $ share - /spare/books rw "Books"

To Mount a TMPFS File System Using the Command Line

1. Assume the system administrator role, and go to an ADMIN_LOW workspace.

2. In a profile shell, enter the mount command, using the -S option followed by any security attributes that you wish to specify.

   $ mount -F tmpfs -S "allowed=all;forced=all" swap /mnt

   The example mounts a tmpfs-type file system, swap, on /mnt.

To Mount a CD-ROM with a HSFS File System

1. As any user or role, use the Device Allocation Manager to allocate the cdrom_N device.

2. If a CD in an allocated CD-ROM device contains a file system, the user is queried whether or not to mount the file system. Answer yes to mount the file system.

To Automatically Launch a CD Player for an Audio CD-ROM

As described in Chapter 12, Managing Devices, under "Mounting an Allocated CD-ROM Device", if an allocated CD-ROM device contains an audio CD and if an audio action is specified in rmmount.conf, the audio action executes.

1. Assume the Security Administrator role in an ADMIN_LOW workspace.

2. Use the Admin Editor action to open the /etc/rmmount.conf file for editing.

3. Add an action to automatically launch a CD player.

   The following example shows how the Security Administrator role could make an action in rmmount.conf for a CD player called workman installed in /usr/bin.

   action cdrom action_workman.so /usr/bin/workman

4. Save and close the file.

   $ :wq

To Listen to an Audio CD as any User or Role

1. Connect the speakers to the CD-ROM device and turn them on.

2. Complete the procedure "To Automatically Launch a CD Player for an Audio CD-ROM".

3. Allocate the audio and the cdrom_N devices at your working label.

4. When prompted, insert the audio CD into the device.

   The specified CD player program is automatically launched.

To Troubleshoot Mount Failures

1. Make sure that the computer sharing the file system has been assigned a template on the Trusted Solaris computer doing the mounting.

   Use the Security Families tool in the Solaris Management Console to confirm that an appropriate template is assigned to an IP address that includes the NFS server. Look for the entry using the toolbox for the appropriate scope. If the NIS+ naming service is being used, bring up the SMC with the NIS+ scope. If NIS is being used, bring up the SMC with the NIS scope. If no naming service is being used, use the Files scope. See "Assigning Security Attributes to Remote Hosts and Network Gateways" for more on how to assign templates to computers.

2. If the computer is not running the Trusted Solaris operating environment, make sure the computer has been assigned a valid label in its template on the Trusted Solaris host.

   The label at which the host accesses the mounted directory must be the same as the label assigned in its template.

3. Ensure that the mount is being done by the administrative role with the mount command in one of its rights profiles.

   In the default configuration, the Security Administrator role specifies the security attributes of mounts while the System Administrator role takes care of the Solaris aspects of mounting.

4. When mounting any file system from a NFS server running Trusted Solaris 1.x, make sure to use the vers=2 and proto=udp options to the mount command.