Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Understanding SMS Security Design
Along with the hardware design for allowing partitioning into dynamic system domains, SMS software enables strict domain separation on the system controller. For instance, the privileges for administrators of one domain can be configured to prevent them from viewing the console output of another domain.
In my experience, I have not seen many data centers actually use this capability. Some people state it is easier to have a single login with full permissions, as is the case with the model provided by the Sun Enterprise™ 10000 server system service processor (SSP). Certainly, this model can be implemented on the Sun Fire 15K server SC. Other people state an unawareness of the capability itself or a lack of understanding of what it can do for them. In today's more security-conscious environment, many customers are reevaluating past decisions regarding security practices. The next several paragraphs discuss security features of SMS software, delve into how it works behind the scenes, and further clarify the rationale for use.
Administrative Privileges
SMS splits functionality into domain and platform administrative privileges, along with a subset of privileges for platform operators and domain configurators. For instance, platform administrators are provided the ability to configure the platform, including assigning boards to domains, getting environmental status, and other administrative tasks. Domain administrators can access the console of the respective domain and perform reconfiguration on the boards assigned to it. However, they cannot perform global configuration as performed by the platform administrator. For a complete description of the various roles and their capabilities, refer to the section on SMS security in the System Management Services (SMS) 1.2 Administrator Guide.
How does SMS split administrative privileges on the SC? Several Solaris OE features come into play to allow this to function properly. In particular, SMS uses Solaris OE groups and access control lists.
Example
Let's begin by taking a look at what user jim can do on a given SC. Logging into the SC as user jim, we can see what this user can do.
f15k-sc0:jim:2> groups staff platadmn platsvc dmnaadmn
User jim is a member of several groups, including the platform administrator group, the platform service group, and the domain A administrator group. Because jim is part of the domain A administrator group, let's snoop around a bit on the SC, and see what we find.
f15k-sc0:jim:15> cd $SMSVAR/adm f15k-sc0:jim:16> pwd /var/opt/SUNWSMS/SMS1.2/adm f15k-sc0:jim:17> ls -ld A drwxrwx---+ 4 root bin 1024 Jul 10 14:08 A
Note the + at the end of the directory permissions. This indicates there is a Solaris OE access control list assigned to this directory. You can use the Solaris OE getfacl command to display the access control list for a directory or file (see the getfacl man page for more information).
f15k-sc0:jim:18> getfacl A # file: A # owner: root # group: bin user::rwx user:jim:rwx #effective:rwx group::rwx #effective:rwx mask:rwx other:---
You might also note that jim has an additional privilege assigned. Without an access control list, only the user root and the group bin would have permissions to this directory. In the preceding sample screen output, you can see that user level permissions have been extended for user jim , effectively making them the same as permissions for the directory owner, root. The following example clearly demonstrates the effect of this.
f15k-sc0:jim:36> cd / f15k-sc0:jim:37> pwd / f15k-sc0:jim:38> ls -ld testfacl drwxrwx--- 2 root bin 512 Aug 7 19:21 testfacl f15k-sc0:jim:39> cd testfacl testfacl: Permission denied
The previous example demonstrates another directory with the same permissions as before, but there is no additional access control list. Note that permission to access that directory is denied to user jim.
The following command shows the empty access control list.
f15k-sc0:jim:40> getfacl testfacl # file: testfacl # owner: root # group: bin user::rwx group::rwx #effective:rwx mask:rwx other:---
To add an access control list, as user root, you would type the following command.
# setfacl -m user:jim:rwx testfacl
See the setfacl man page for more information about adding access control lists. Essentially, adding an access control list using the preceding command gives jim the same permissions that user root already has. Here's the result:
f15k-sc0:jim:51> ls -ld testfacl drwxrwx---+ 2 root bin 512 Aug 7 19:34 testfacl f15k-sc0:jim:52> getfacl testfacl # file: testfacl # owner: root # group: bin user::rwx user:jim:rwx #effective:rwx group::rwx #effective:rwx mask:rwx other:--- f15k-sc0:jim:53> cd testfacl f15k-sc0:jim:54> ls f15k-sc0:jim:55> touch t.t f15k-sc0:jim:56> ls -l total 0 -rw-r----- 1 jim staff 0 Aug 7 19:34 t.t
Even though the normal permissions of the directory would not allow jim to list directory contents or create a file, the access control list allows this capability. Does this mean you need to configure the access control lists for SMS software yourself? No. SMS software includes a utility called smsconfig that adds users to the appropriate groups and maintains appropriate access control list permissions.
Earlier, I mentioned that user jim was a member of several groups, but then segued into a discussion on access control lists. Let's go back to the group mechanism for just a bit. The Solaris OE groups are mainly used by SMS commands before the functionality of that command is executed. Essentially, a library call is made to determine if the user executing the command is in the appropriate Solaris OE group that is eligible to execute the particluar command. If it is not in the appropriate group, an appropriate message is printed. If it is in the appropriate group, the command is executed.
Now you can see how SMS software uses the Solaris OE access control list and group mechanisms to implement this facet of SMS security. If you are trying to determine why a given user cannot issue a particular command or edit a file in a particular directory as expected, you are now armed with the tools to discover the reason. Now, with a better understanding of this SMS software feature and the Solaris OE, you can use this feature to manage your Sun Fire 15K server platform in a more secure fashion.
If you are hosting multiple projects run by multiple departments with multiple administrators in multiple domains, utilizing these features provides several benefits. The separation of responsibility becomes obvious and helps with accountability. You no longer have a long list of possible suspects who may have reconfigured the critical domain. Instead, you have a limited few who possess the appropriate permissions.