Change Manager uses secure communication and file transfer channels when available and as described for these security issues:
Communications between the browser and the browser user interface is achieved by using secure HTTP. Users are required to log in to the browser interface.
A user is identified by his or her UNIX user name. A server is identified by its host name.
User identity is initially proven using standard Solaris mechanisms. Subsequent transactions use reauthentication provided by the servlet session framework. Server identity is proven through the use of a self-signed certificate.
Authorization is performed by standard Sun Management Center mechanisms, as described in the Sun Management Center 3.0 Software User's Guide. These mechanisms offer per-user, per-operation control at the service level and per-user, per-operation, and per-target control at the agent level. Change Manager respects Sun Management Center authorization data, but does not provide a user interface mechanism to manipulate it.
Only rudimentary control access to Change Manager data is currently supported. All users who are authorized to use a Change Manager service are able to access all Change Manager data associated with that service.
Secure HTTP mechanisms are used to encrypt traffic between the browser and the user interface.
The combination of encryption and authentication precludes productive corruption of the traffic.
Flood attacks and corruption attacks can disrupt service. Underlying Solaris authentication mechanisms might optionally implement an authentication failure lockout policy. Such a lockout policy might enable denial of service attacks.
Logins and user-level actions are logged.
The file import function is performed by using HTTP and traditional file system mechanisms. The file export function is performed by using traditional file system mechanisms. Using secure HTTP to perform file transfers is not planned at this time.
File system-based import and export functions use the user's UNIX identity. File imports that use HTTP are anonymous.
No particular authentication is done as the user's UNIX identity is already authenticated. Note that file system mechanisms include NFS, and NFS authentication is notoriously weak.
File system access is performed by using the user's UNIX identity and by applying traditional file system access controls. HTTP access does not provide for authorization.
Local file system access is confidential. NFS access is likely to be exposed. HTTP access will be exposed.
Local file system access is considered trustworthy. NFS access is likely to be vulnerable to productive corruption. HTTP access is likely to be vulnerable to productive corruption.
Flood attacks and corruption attacks might disrupt service.
User-level actions are logged by Change Manager. For local and NFS access, little or no logging is performed, although file ownership and timestamps provide some accountability. HTTP access provides very limited logging.
The browser user interface and the command-line interface use Sun Management Center Remote Method Invocation (RMI) mechanisms to communicate with the server layer. Security issues are exactly as for Sun Management Center's other user interfaces.
UNIX user name.
UNIX password.
Authorization is performed by Sun Management Center service and agent authorization mechanisms.
Only rudimentary control access to Change Manager data is currently supported. All users who are authorized to use a Change Manager service are able to access all Change Manager data associated with that service.
Traffic cannot be intercepted by applications such as snoop.
Traffic cannot be corrupted.
Flood attacks might disrupt service. Underlying Solaris authentication mechanisms might optionally implement an authentication failure lockout policy. Such a lockout policy might enable denial of service attacks.
Logins and user-level actions are logged.
UNIX user name.
This issue is covered by other areas. The authenticated UNIX user identity is trusted.
Standard file system access controls are used to prevent unauthorized access to Change Manager data files. Files and directories are owned by superuser and are not publically readable or writable.
Standard Sun Management Center and Oracle access controls are used to prevent unauthorized access to Change Manager database contents.
Note that NFS allows some access to Change Manager data.
Files are protected as described for Authorization.
Local file access is considered to be trustworthy.
Denial of service through disk space exhaustion is a possible issue. In such cases, the user is advised to locate Change Manager data on a dedicated file system that does not allow access by ordinary users.
Only standard file system ownership mechanisms are provided to address accountability.
Same as for Sun Management Center.
Same as for Sun Management Center and SNMPv2usec.
Same as for Sun Management Center. Per-user, per-target, and per-operation ACLs are respected, although the Change Manager user interface does not offer a mechanism to manage them.
Same as for Sun Management Center.
Same as for Sun Management Center.
Flood attacks and corruption attacks might disrupt service.
Same as for Sun Management Center.
Managed hosts log all actions.
Change Manager uses a private protocol between the Sun Management Center server and agent to perform particular management operations. This protocol relies on a Sun Management Center "probe connection," which provides a data stream between server and agent. The probe mechanism relies on standard Sun Management Center authentication to ensure proper access to the Change Manager components on the agent. The agent must be properly configured and must be in the appropriate server context before a probe connection can be established.
The server and the agent are in a "trusted" relationship according to Sun Management Center server context security.
The user must be authorized on the server. An interloper might eavesdrop on the initiation of the probe connection and grab credentials from the agent during initial handshake. This ability would allow unauthenticated access to the agent from a rogue server. Access by a rogue agent to server data through this mechanism is impractical, according to standard Sun Management Center server context security mechanisms.
An authenticated Sun Management Center user must have SNMP-set and SNMP-write access to the Change Manager Management Information Base (MIB). This access is managed by agent-side Access Control Lists (ACLs) according to Sun Management Center. The default access enables any authorized Change Manager user to have access to the Change Manager MIB.
Same as for Sun Management Center, which means little or no confidentiality.
Data is vulnerable to productive corruption attacks.
Flood attacks and corruption attacks might disrupt service. Service might be disrupted by unauthorized use of a snooped connection startup request. The interruption of Change Manager processes on an agent causes management operations to fail. Excessive system load or other resource constraints on an agent can affect Change Manager processes.
Data transfers are logged by both the Change Manager server and the managed host, including managed host identification and the responsible user.
Change Manager supports the standard Reverse Address Resolution Protocol (RARP) services for initial installations.
MAC address.
None.
No authorization check is performed for the requesting client, which does not appear as a serious vulnerability.
No authorization check is done for the responding server, which is a potentially serious vulnerability as it might allow a rogue server to subvert an initial installation.
None.
None.
Flood attacks and corruption attacks might disrupt service.
None.
Change Manager supports the standard bootparams services for initial installations.
IP address.
None.
No authorization check is done for the requesting client, which does not appear as a serious vulnerability.
No authorization check is done for the responding server, which is a potentially serious vulnerability as it might allow a rogue server to subvert an initial installation.
None.
None.
Flood attacks and corruption attacks might disrupt service.
None.
None.
None.
No authorization check is done for the requesting client, which does not appear as a serious vulnerability, as the only data transferred is a standard Solaris bootstrap.
No authorization check is done for the supplying server, which is a potentially serious vulnerability as a rogue server could subvert the installation process.
None, which does not appear as a serious vulnerability, as the only data transferred is a standard Solaris bootstrap.
None. Initial installation is vulnerable to productive corruption attacks.
Flood attacks and corruption attacks might disrupt service.
None.
IP address.
Host - None. The IP address is presumed trustworthy, which is a serious vulnerability as it might allow a villain using a spoofed IP address to retrieve sensitive data. Notably, if a managed host is enabled for initial installation, a villain might be able to retrieve a Solaris Flash archive.
User - Weak. The target is assumed trustworthy. A villain with superuser privileges on the target can retrieve potentially sensitive data.
By IP address, using NFS share restrictions.
By standard file access controls.
None, which is a serious vulnerability, as on initial installation it might allow a villain to snoop retrieval of a Solaris Flash archive.
None, which is a serious vulnerability as it might allow productive corruption attacks on both initial installation and update.
Flood attacks and corruption attacks might disrupt service.
None.
Terminal access is not strictly a part of the Change Manager product. However, a user that accesses the Change Manager command-line interface through mechanisms such as telnet, rlogin, or ssh is vulnerable to all of the traditional vulnerabilities of those mechanisms.