Skip Navigation Links | |
Exit Print View | |
Oracle Solaris 11.1 Administration: Security Services Oracle Solaris 11.1 Information Library |
1. Security Services (Overview)
Part II System, File, and Device Security
2. Managing Machine Security (Overview)
Controlling Access to a Computer System
Controlling Access to Machine Resources
Address Space Layout Randomization
Limiting and Monitoring Superuser Access
Configuring Role-Based Access Control to Replace Superuser
Preventing Unintentional Misuse of System Resources
Assigning a Restricted Shell to Users
Restricting Access to Data in Files
Restricting setuid Executable Files
Using the Secure by Default Configuration
Using Resource Management Features
Monitoring Use of Machine Resources
Authentication and Authorization for Remote Access
Encryption and Firewall Systems
3. Controlling Access to Systems (Tasks)
4. Virus Scanning Service (Tasks)
5. Controlling Access to Devices (Tasks)
6. Verifying File Integrity by Using BART (Tasks)
7. Controlling Access to Files (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Security Attributes in Oracle Solaris (Reference)
Part IV Cryptographic Services
11. Cryptographic Framework (Overview)
12. Cryptographic Framework (Tasks)
Part V Authentication Services and Secure Communication
14. Using Pluggable Authentication Modules
17. Using Simple Authentication and Security Layer
18. Network Services Authentication (Tasks)
19. Introduction to the Kerberos Service
20. Planning for the Kerberos Service
21. Configuring the Kerberos Service (Tasks)
22. Kerberos Error Messages and Troubleshooting
23. Administering Kerberos Principals and Policies (Tasks)
24. Using Kerberos Applications (Tasks)
25. The Kerberos Service (Reference)
Oracle Solaris is a multiuser environment. In a multiuser environment, all the users who are logged in to a system can read files that belong to other users. With the appropriate file permissions, users can also use files that belong to other users. For more discussion, see Chapter 7, Controlling Access to Files (Tasks). For step-by-step instructions on setting appropriate permissions on files, see Protecting Files (Tasks).
You can keep a file secure by making the file inaccessible to other users. For example, a file with permissions of 600 cannot be read except by its owner and by the root account. A directory with permissions of 700 is similarly inaccessible. However, someone who guesses your password or who discovers the root password can access that file. Also, the otherwise inaccessible file is preserved on a backup tape every time that the system files are backed up to offline media.
ZFS file systems can be created with on-disk encryption. For more information, see Encrypting ZFS File Systems in Oracle Solaris 11.1 Administration: ZFS File Systems.
The Cryptographic Framework provides digest, mac, and encrypt commands. Regular users can use these commands to protect files and directories. For more information, see Chapter 11, Cryptographic Framework (Overview).
ACLs, pronounced “ackkls,” can provide greater control over file permissions. You add ACLs when traditional UNIX file protections are not sufficient. Traditional UNIX file protections provide read, write, and execute permissions for the three user classes: owner, group, and other. An ACL provides finer-grained file security.
ACLs enable you to define fine-grained file permissions, including the following:
Owner file permissions
File permissions for the owner's group
File permissions for other users who are outside the owner's group
File permissions for specific users
File permissions for specific groups
Default permissions for each of the previous categories
To protect ZFS files with access control lists (ACLs), see Chapter 7, Using ACLs and Attributes to Protect Oracle Solaris ZFS Files, in Oracle Solaris 11.1 Administration: ZFS File Systems. For information about using ACLs on legacy file systems, see Using Access Control Lists to Protect UFS Files.
A network file server can control which files are available for sharing. A network file server can also control which clients have access to the files, and what type of access is permitted for those clients. In general, the file server can grant read-write access or read-only access either to all clients or to specific clients. Access control is specified when resources are made available with the share command.
When you create an NFS share of a ZFS file system, the file system is permanently shared until you remove the share. SMF automatically manages the share when the system is rebooted. For more information, see Oracle Solaris ZFS and Traditional File System Differences in Oracle Solaris 11.1 Administration: ZFS File Systems.
In general, superuser is not allowed root access to file systems that are shared across the network. The NFS system prevents root access to mounted file systems by changing the user of the requester to the user nobody with the user ID 60001. The access rights of user nobody are the same as those access rights that are given to the public. The user nobody has the access rights of a user without credentials. For example, if the public has only execute permission for a file, then user nobody can only execute that file.
An NFS server can grant root access to a shared file system on a per-host basis. To grant these privileges, use the root=hostname option to the share command. You should use this option with care. For a discussion of security options with NFS, see Chapter 3, Accessing Network File Systems (Reference), in Managing Network File Systems in Oracle Solaris 11.1.