|
|
Controlling access devices on a Solaris operating system is accomplished by two mechanisms: device policy and device allocation. In essence, device policy is a default kernel-level mechanism that restricts and prevents access to devices that are integral to the system by mandating that processes that open such a device—for example, a network interface—require certain privileges, such as reading and writing. Device allocation, which is not enabled by default, is enforced during user allocation to require user authorization in order to access a peripheral device such as a CD-ROM or printer.
| Exam Watch |
For the exam, you should remember that device policy is enabled by default and enforced in the kernel to restrict and prevent access to devices that are integral to the system. Device allocation is not enabled by default and is enforced during user allocation time to require user authorization to access peripheral devices. |
This section contains discussions on using both device policy and device allocation to mitigate security risks associated with peripheral devices and devices integral to the system. Since some devices are integral to the system, they can pose serious security consequences if accessed inappropriately.
The Solaris kernel enforces device policy to restrict or completely prevent access to devices that are integral to the system. We'll discuss several tasks that comply with the exam requirements with regard to configuring device policy. These tasks include listing device policies, adding and modifying device policies, removing device policies, and auditing device policies.
Viewing the device policies for all devices or for a particular device that is integral to the system is easy using the getdevpolicy command. For example, to view the device policy for all integral devices on the system, issue the getdevpolicy | more command. Following is the typical output from a standard Solaris installation:
# getdevpolicy | more
DEFAULT
read_priv_set=none
write_priv_set=none
ip:*
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
icmp:*
read_priv_set=net_icmpaccess
write_priv_set=net_icmpaccess
hme:*
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
eri:*
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
sad:admin
read_priv_set=sys_config
write_priv_set=sys_config
mm:allkmem
read_priv_set=all
write_priv_set=all
mm:kmem
read_priv_set=none
write_priv_set=all
mm:mem
read_priv_set=none
write_priv_set=all
ce:*
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
fssnap:ctl
read_priv_set=sys_config
write_priv_set=sys_config
ge:*
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
qfe:*
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
md:admin
read_priv_set=none
write_priv_set=sys_config
envctrltwo:*
read_priv_set=sys_config
write_priv_set=sys_config
keysock:*
read_priv_set=sys_net_config
write_priv_set=sys_net_config
ipsecah:*
read_priv_set=sys_net_config
write_priv_set=sys_net_config
ipsecesp:*
read_priv_set=sys_net_config
write_priv_set=sys_net_config
ip6:*
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
icmp6:*
read_priv_set=net_icmpaccess
write_priv_set=net_icmpaccess
random:*
read_priv_set=none
write_priv_set=sys_devices
spdsock:*
read_priv_set=sys_net_config
write_priv_set=sys_net_config
bge:*
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
dmfe:*
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
Using the same command, but following a specific device or devices (separated by spaces), the system will list the device policy for each of them in procession, as shown next:
# getdevpolicy /dev/hme /dev/mem
/dev/hme
read_priv_set=net_rawaccess
write_priv_set=net_rawaccess
/dev/mem
read_priv_set=none
write_priv_set=all
Device policy is enabled by default, and therefore, it contains a default configuration. When attempting to adhere to company policy or to deal with other specific cases, you may find that you need to modify an existing device policy. Doing so can be accomplished in two steps:
| Exam Watch |
Remember for the exam that the getdevpolicy command is used to view device policy for all integral devices on the system. Also know that device policy restricts and prevents access to devices. |
Log in with an account that has root or Device Security privileges, or use the su command to become superuser.
Issue the update_drv -a -p policy device-driver command; where policy is the device policy or policies (separated by a space) for device-driver, which is the device driver whose device policy you wish to modify.
If you need to add a new device driver to the system altogether, you can issue this command:
add_drv -b basedir -c class_name -i identify_name -m permission -n -f -v device_driver
where
-b basedir installs the driver on the system with a root directory of basedir
-c class_name refers to the driver being added to the system to export the class class_name
-i identify_name is a white space–separated list of aliases for the driver device_driver
-m permission specifies the file system permissions for device nodes created by the system on behalf of device_driver
-n means to not try to load and attach device_driver but instead just modify the system configuration files for the device_driver
-f forces add_drv to add the driver even if a reconfiguration boot is required
-v causes add_drv to provide additional information regarding the success or failure of a driver's configuration into the system
device_driver is the new device driver being added
Removing Device Policies To remove a device policy for a specific device, you simply modify the device policy by specifying only the policy you wish to enable. For example, if you need to remove the read set of privileges from the ipnat device, you would assume the appropriate user privileges and issue this command:
update_drv -a -p write_priv_set=net_rawaccess ipnat
In this example, the read set of privileges would be removed from the ipnat device policy.
Additionally, you can issue the rem_drv device_driver command to remove a device or device driver. You should also always confirm any changes you make to device policies by issuing the getdevpolicy /dev/ipnat command.
| Exam Watch |
For the exam, you'll need to know the command to modify or remove device policies for a specific device. As indicated in the text, you should use the update_drv -a -p policy device-driver command; where policy is the device policy or policies (separated by a space) for device-driver, which is the device driver whose device policy you wish to modify or remove. |
The Solaris auditing subsystem can be used to audit changes in device policy. The audit event AUE_MODDEVPLCY is included in the as audit class, which can be used to audit device policies. (See Chapter 5 for details on how to configure and manage the auditing subsystem.)
To audit device policies, you'll need to add the as class to the audit_control file flags argument. This defines which attributable events should be audited for the entire system, and it includes all users on the system. Events can be added to the flags argument separated by commas. Following is a sample extract:
# ident "@(#)audit_control.txt 1.4 00/07/17 SMI" # dir:/var/audit/1/data dir:/var/audit/2/data dir:/var/audit flags:lo,as minfree:25 naflags:lo,na
In this extract, the attributable lo and as class events will be audited for all users on the system. On the other hand, to configure the auditing subsystem not to audit the class that includes the device policy audit event (the as class), simply edit out the class selection and save the file.
| Exam Watch |
To audit device policies you'll need to add the as class to the audit_control file flags argument which defines auditing attributes for the entire system and all of the system's users. |
The Solaris auditing kernel enforces device allocation, which is used to prevent or restrict access to peripheral devices. Users will require the appropriate authorization to access allocatable devices. We'll discuss several tasks in this section to comply with the exam requirements regarding device allocation. These tasks include making devices allocatable, viewing device allocation information, auditing device allocation, allocating and mounting a device, and deallocating a device.
After starting the auditing subsystem, device allocation will be enabled on the system. To do this, you assume superuser or the Primary Administrator role and run the bsmconv script, located in /etc/security, with the ./bsmconv command. This script is used to enable the Basic Security Module (BSM), which starts the auditing subsystem.
To enable the auditing services, follow these steps:
Log in with an account that has root privileges, or use the su command to become superuser.
Bring down the system to single-user mode using the init 1 command.
In the /etc/security directory, run the bsmconv script to enable the auditing service: ./bsmconv
Bring the system into multi-user mode using the init 6 command.
Viewing Device Allocation Information To view allocation information about a device, you must assume superuser or a role that has Device Security rights. At that point, simply display information about allocatable devices by issuing the list_devices device-name command; where device-name is audio (for microphone and speakers), fd(n) (for diskette drive), sr(n) (for CD-ROM drive), and st(n) (for tape drive). The (n) specifies the number of the device. See the list_devices command man page for more details and examples.
| Exam Watch |
With root privileges, run the bsmconv script to enable the auditing service. By doing so you'll also enable device allocation, which is enforced by the kernel to prevent/restrict access to devices. |
The Solaris auditing subsystem can also be used to audit device allocation. The audit class OTHER (ot) is used to audit allocatable devices. (Be sure to review Chapter 5 for details on how to configure the auditing subsystem properly.)
To audit device allocation, you'll need to add the ot class to the audit_control file flags argument, which defines which attributable class events should be audited for the entire system. Events added to the flags argument are separated by commas. Following is an example:
# ident "@(#)audit_control.txt 1.4 00/07/17 SMI" # dir:/var/audit/1/data dir:/var/audit/2/data dir:/var/audit flags:lo,as,ot minfree:25 naflags:lo,na
In this extract, the attributable lo, as, and ot class events will be audited for all users on the system. On the other hand, to configure the auditing subsystem not to audit the class that includes device allocation (again, the ot class), simply edit out that class selection and save the file.
| Exam Watch |
The ot audit class is used to audit device allocation. To audit allocatable devices, you'll need to add the ot class to the audit_control file flags argument. |
Before a user can allocate a device, he or she needs to be authorized to do so. Sun provides the following four steps for granting authorization:
Assume the Primary Administrator role, or become superuser.
Create a rights profile that contains the appropriate authorization and commands. Typically, you would create a rights profile that includes the solaris.device.allocate authorization. (See Chapter 9 for security implications when creating or changing a rights profile.) Give the rights profile appropriate properties, such as the following:
Rights profile name: Device Allocation
Granted authorizations: solaris.device.allocate
Commands with security attributes: mount with the sys_mount privilege, and umount with the sys_mount privilege
Create a role for the rights profile, and use the following role properties as a guide:
Role name: devicealloc
Role full name: Device Allocator
Role description: Allocates and mounts allocated devices
Rights profile: Device Allocation (This rights profile must be at the top of the list of profiles that are included in the role.)
Assign the role to every user who is permitted to allocate a device.
At this point, a user with the appropriate rights and authorization can allocate a device simply by issuing the allocate command. For example, to allocate tape drive 0, the user would issue allocate st0. As another example, if the user wishes to allocate a microphone, he or she would issue the allocate audio command. Finally, let's say the user wishes to allocate sales-printer-1. To do so, the following command would be executed: allocate /dev/lp/sales-printer-1.
Forcing Allocation Unfortunately, if a device is allocated by another user, it will not be available for allocation to a new user. To remedy that quickly, you can forcibly deallocate a device, which we'll talk more about later, or forcibly allocate (which is to reallocate) a device. To verify that you have the appropriate rights (such as solaris.device.revoke) to do this, you can issue the auths command:
$ auths Solaris.device.allocate solaris.device.revoke
After confirming that you have authorization, to allocate a device forcibly, you must issue the allocate -U user-name command, where user-name is the name of the user to which you will forcibly allocate the device.
| Exam Watch |
Users need the appropriate rights and authorization to allocate and deallocate devices. The authorization required to allocate a device is solaris.device.allocate. The authorization required to allocate or deallocate a device forcibly is solaris.device.revoke. |
Mounting an Allocated Device Though this is not typically covered by the exam, it's important to note that after a device is allocated, you must mount it to the system before you can use it. Following are Sun's recommended steps for doing so:
Assume a role that can allocate and mount a device.
Create and protect a mount point in the role's home directory. You need to do this step only the first time you need a mount point:
mkdir mount-point ; chmod 700 mount-point
List the allocatable devices:
list_devices -l
Allocate the device:
allocate device-name
Mount the device:
mount -o ro -F filesystem-type device-path mount-point
-o ro indicates that the device is to be mounted read-only. Use-o rw to indicate that you should be able to write to the device.
-F filesystem-type indicates the file system format of the device. Typically, a CD-ROM is formatted with an HSFS file system. A diskette is typically formatted with a PCFS file system.
device-path indicates the path to the device. The output of the list_devices -l command includes the device-path.
mount-point indicates the mount point that you created in step 2.
If a device is allocated and mounted, to deallocate it safely you must first unmount it and then deallocate it by issuing all of the following commands:
cd $HOME
unmount mount-point
deallocate device-name
| Exam Watch |
Users with the appropriate rights and authorization can allocate a device by issuing the allocate device-name command and deallocate a device by issuing the deallocate device-name command. |
As mentioned earlier, you can forcibly deallocate a device by issuing the deallocate -F device command. For example, to force the deallocation of the printer (also mentioned earlier) you would issue this command: deallocate/dev/lp/sales-printer-1
 |
Following are steps for checking whether or not you have the appropriate allocation authorization; if you do, you can then allocate CD-ROM(0):
Log in with your user account.
From a terminal session, issue the auths command and verify that you have solaris.device .allocate device allocation authorization rights.
Allocate the CD-ROM by issuing the allocate sr0 command.
|
|
|