Install Time Security

Install-Time Security

Copyright 2007, Sun Microsystems, Inc

Policy Synopsis

Policy for security during and as a result of product installation.

Contents

• Applicability
• Background
• Policy
• Exemptions
• Appeals

Overview

Applicability

All projects

Background

This policy is intended as a modest step in improving security, not as "ultimate" security. The policy does not preclude non-secure installations of products, it simply requires secure installation by default and informed administrator action to choose a non-secure installation. This policy is intended to initiate a fundamental shift in mindset, but it is expected to result in gradual rather than instantaneous change, with the usual balancing of business and technical objectives.

Policy

• Applies to All projects
• Authority SAC
• Effective September 15, 2006
• Policy All products must provide Install-Time Security as defined in this policy.
• Details

  DEFINITIONS

  A secure execution of a product installation is one that at no time introduces any vulnerabilities or exposures when the product is on a network or on a multi-user system. All accessible networks must be assumed to be actively hostile to the product. All on-system users and applications that don't have the same or greater privileges as the installed product must be assumed to be actively hostile to the product.

  A product provides Install-Time Security if all of its installation procedures are designed such that:

  • secure execution is maintained to the extent the administrator is never asked for input, and
  • each time the administrator is asked for input, at least one choice will maintain secure execution, and if a default is provided, accepting the default will maintain secure execution, and
  • each time the administrator is asked for input, either:
    • secure execution is maintained no matter what input the administrator provides, or
    • choices that maintain secure execution are clearly differentiated from those that violate secure execution, or
    • the administrator is warned and asked for confirmation when a choice is made that violates secure execution

  An internal interconnect is any mechanism that allows a process to communicate with other processes on the local system. These include, but are not limited to, Inter Process Communications (IPC) mechanisms such as Unix-domain sockets, doors, named pipes, System V IPC, etc.

  A service is a component that initiates or accepts communication on one or more external networks or internal interconnects.

  A vulnerability or exposure is a state in a service or the file system, which allows a network-based or on-system attacker to:

  • execute commands as another user,
  • access or transfer data in a manner contrary to the specified access policy for that data,
  • pose as another entity,
  • conduct a denial of service that could reasonably be prevented,
  • gather information that could lead to a compromise of the system,
  • gather information that could be considered sensitive under some reasonable customer security policy, or
  • compromise the system using a capability that behaves as intended.

  [This last definition was adapted from http://www.cve.mitre.org/about/terminology.html#Def]

  SERVICE GUIDANCE

  For each service that is created, installed, used, or depended on by the product, there are four ways to achieve secure execution:

  SVC1

  Do not install the components that comprise the service.

  SVC2

  Ensure that the service is never enabled or automatically used by the product itself, during or as a result of installation. (There is no requirement to prevent layered products or post-install administration from enabling or using the service.)

  SVC3

  Ensure that the service is always enabled or automatically used by the product itself in a way that satisfies all of the minimum security requirements specified further below, both during and as a result of installation. (There is no requirement to prevent layered products or post-install administration from enabling or using the service in ways that do not satisfy the minimum security requirements.)

  SVC4

  Ensure that failure to satisfy the minimum security requirements introduces no vulnerabilities or exposures.

  The SVC1 approach is often an important option to provide in addition to one or more of the other approaches, but careful consideration should be given to its potential impact on subsequent administration of the system before making it the default. If a service is pre-installed, such that the customer has not explicitly expressed a desire to use the service, or if the service is installed as part of a larger suite such that customer use of the service is not a high probability, the SVC2 approach should be strongly favored as the default. If installation conveys an explicit or high probability of customer use of the service (for example, active install of a dedicated-use product), the SVC3 approach should be favored as the default.

  For an inbound service (one that listens for inbound communication from one or more networks or interconnects), the minimum security requirements, all of which must be satisfied, are:

  IN1

  Access control must be enforced for inbound communication, with a "default deny" authorization policy. That is, by default all inbound requests must be rejected, in such a way that no vulnerabilities or exposures are introduced by any data communicated as part of that rejection. As an exception, access can be granted when the communication occurs over a purely internal interconnect that authenticates the accessing entity as having at least the same privileges as those of the executing service.

  IN2

  The access control check must be made as early as possible relative to processing inbound data, to avoid or minimize content-based attacks.

  Note that authentication of the "requestor" of the inbound communication is not required to satisfy these requirements. For purely local interconnects, if file system permissions are used as the sole means of access control, the permissions set by the installation can only permit owner access.

  For an outbound service (one that initiates outbound communication on one or more networks or interconnects), the minimum security requirements, all of which must be satisfied, are:

  OUT1

  The "receiver" of the outbound communication must be authenticated in a manner that introduces no vulnerabilities or exposures.

  OUT2

  Authentication of the receiver must occur prior to revealing any data that could be potentially sensitive or could lead to compromise, and must occur as early as possible relative to processing inbound data to avoid or minimize content-based attacks.

  OUT3

  Data integrity must be maintained on both outbound and inbound communication, and confidentiality (via encryption) must be maintained on both outbound and inbound network communication for any data that could be potentially sensitive or could lead to compromise.

  Note that authentication of the receiver is not restricted to just connection-based authentication. Encrypting data in such a way that only the receiver can decrypt it is an acceptable means of authentication. Also note that network services are not required to use IP Security Protocol (IPsec); Kerberos, SSL/TLS, and SSH are all examples of protocols that can readily be used in ways that will satisfy the minimum security requirements.

  This policy is not intended to eliminate all possible denial of service attacks; rather, it is aimed at those denial of service attacks which can reasonably be prevented, in the layer/product that is appropriate for the task, while still remaining compliant with applicable standards. For example, layered product services are not expected to be concerned with preventing TCP SYN flooding, but services that use Java object serialization should be concerned with memory allocation and computation attacks that could be launched simply by crafting small custom byte stream sequences. Good engineering judgment will be required to determine which attacks must be dealt with.

  In both the SVC3 and SVC4 approaches, particular care must be taken to prevent information gathering activities (but note this policy is not aimed at preventing fingerprinting or similar forensic techniques from being used to infer information). Even information that might seem benign can often be considered sensitive. For example, in an inbound HTTP service, the "Server" response header typically includes product and version information that customers may reasonably consider to be sensitive; this information might be included unwittingly in all responses in the SVC4 approach, and even in rejection responses in the SVC3 approach. It is therefore critical that enabled services be carefully evaluated for such exposures. In general, the "default deny" authorization policy (specified in requirement IN1) should be implemented by revealing as little information as possible to the requestor; in so doing, sensitive information will be excluded automatically, without actually having to determine if the information is sensitive.

  FILE SYSTEM GUIDANCE

  File permissions

  FS1

  Regular files created by an installation must not be world writable. Any exceptions to this rule must be justified as introducing no security issues.

  FS2

   Files containing security-related secrets (such as passwords or private keys), or containing data that could be considered sensitive under some reasonable customer security policy, must comply with the SAC policy titled Storing Reusable Passwords on a Filesystem.

  FS3

   For executable files, the "set user ID" and "set group ID" bits must not be used. Any exceptions to this rule must be justified as introducing no security issues.

  FS4

   Files must be created with uids/gids that map to an existing user/group in the system.

  Directory permissions

  FS5

  Directories created by an installation must not be world writable. Any exceptions to this rule must be justified as introducing no security issues. If a directory is world writable, the sticky bit must be set to restrict permission to remove and rename files.

  FS6

   If directories have inheritable permissions, those permissions must comply with the file and directory permissions guidance.

  FS7

   Directories must be created with uids/gids that map to an existing user/group in the system.

  There are, otherwise, no restrictions on owner permissions, group permissions and access control lists (ACLs).
  OTHER GUIDANCE

  OTH1

   Installation procedures must minimize the privileges required to perform the installation. Any administrator with the required privileges must be able to perform the installation.

  There are no auditing, logging, or non-repudiation requirements for Install-Time Security. Auditing and logging provide a recorded trail of events and errors that are often invaluable for security analysis and troubleshooting. Given this, it is strongly encouraged that local auditing and logging of basic security-relevant events also be enabled by default for any services enabled by the installation.

Exemptions

Vulnerabilities or exposures resulting from compliance with an external standard are exempt from this policy. However, the administrator must be warned of this condition. Also, the product teams are strongly encouraged to investigate the use of secure alternatives.

This policy should be taken into account when evaluating candidate third party products for delivery as Sun badged products under OEM deals or reseller agreements.

Appeals

Appeals go to the ARC.