Sun^TM Solaris^TM = Security

This White Paper provides a complete set of = security=20 features and describes the four levels of protection = included in=20 Solaris^TM:=20

Level 1 consists of features and tools that help=20 administrators tightly control who can log onto the = system.=20

Level 2 describes tools that enable administrators to = set the=20 overall security state of the system.

Level 3 covers Secure Distributed services and = Developers=20 Platforms, describing how Solaris supports different=20 authentication and encryption mechanisms.

Level 4 describes the tools to control access to the = physical=20 network.

Security: A Key Issue for the Global=20 Corporation

The fact that stand-alone data centers with fully = centralized=20 security requirements are fading rapidly from modern = corporate=20 computing environments is well documented. More cost = effective and=20 efficient distributed environments in which client systems = are=20 separated from servers over a network continue to = proliferate. In=20 addition, interconnections between commercial, private, and=20 government institutions worldwide are expanding the = community of=20 users who can potentially gain access to internal corporate=20 resources.

Concurrently, users are becoming more knowledgeable and=20 sophisticated. Unfortunately, some have used their knowledge = for=20 unscrupulous purposes. Although famous "hackers" continue to = grab=20 media headlines, studies have shown that a great majority of = computer crimes go undetected. These trends have all given = rise to=20 fundamental changes in the security requirements for the = global=20 corporation.

It is no wonder that security has emerged as a key issue = for=20 companies wishing to capitalize on the benefits of = implementing=20 global distributed systems, without risking the privacy and=20 integrity of sensitive information. System and network=20 administrators therefore must be able to choose products = that offer=20 a full spectrum of features that address their changing = security=20 needs.

Sun's Solaris solution offers a fully complete set of = security=20 features that suit the varying requirements of contemporary=20 corporate computing environments:=20

It offers automated tools that simplify the = configuration of=20 the security state of the system, and report potential = security=20 vulnerabilities.

It provides secure distributed file and directory = services and=20 platforms for development of secure applications. =

It supports important US and international standards = as well=20 as the latest Internet security features.

Finally, third-party products complement what is = available=20 from Sun giving corporations a full spectrum of protection = against=20 potential security violations.

Solaris: The Secure Solution =

Solaris from Sun protects against unwanted intrusions = with a=20 multi- dimensional approach to system and network security = (See=20 Figure 1). The Solaris four level protection plan lets=20 administrators:

Control who can log in to the system

Control the accessibility of system resources to = logged in=20 users and programs

Implement secure distributed file and directory = services and=20 provide platforms for development of secure applications = and=20 services

Control access to the network itself

Figure 1 Four dimensions of Solaris = Security=20

The following sections cover the four dimensions of = Solaris=20 security in more detail.

Level 1: Controlling Login Access on = Solaris

The first level of Solaris security control consists of = features=20 and tools that help administrators tightly control who can = log in to=20 the system. Central to this purpose is the use of a password = which=20 can be used to check the identity of the person who is = attempting to=20 log in. In other words, if one assumes the password is known = only to=20 it's owner, it can be used to prove that the individual who = is=20 attempting to log in is indeed "authentic" and is = acknowledged to=20 have been granted the "right" to log in to the system.

Unfortunately, the system is unable to determine if the = password=20 is being used by someone other than it's owner. It for this = reason=20 that protecting passwords is of the utmost importance. = Solaris has=20 many features that control the creation, use and safe = storage of=20 passwords. These are known collectively as password = management=20 features and they include the following:

Password validation: Solaris compares the = password=20 the user provides to the one set by and stored for that = user in a=20 special file (see "Shadow Password File below). If the = passwords=20 match, the user is allowed to log in.

Password aging: Solaris enables the = administrator to=20 set an expiration date for passwords. Solaris will warn = the user=20 that the password is about ready to expire and ask for a = new one=20 to be set. Once the password expires, if a new one hasn't = been=20 set, a log in attempt will be refused. (Note that NIS+ on = Solaris=20 2.5 includes support for domain wide password aging.) =

Disallow old password: The longer a password = is=20 around, the more likely it is that someone will be able to = find=20 out what it is. This feature prevents a user from reusing = a=20 previously used password.

Password qualification: Solaris helps ensure = that you=20 will create a password that will be more difficult for = someone=20 else to guess. It does this by checking to see if the = password has=20 the correct number of characters and/or symbols. =

Shadow password file: This "hidden" file = (called=20 /etc./shadow) stores all users' passwords and is readable = only by=20 root. Before the implementation of the shadow password = file, other=20 privileged users were able to access the password file. =

Account expiration: This enables a system=20 administrator to set an expiration date for an account. = After the=20 date expires, the account is no longer active.

The Sun Security Manager product line offers products for = Solaris=20 that impose further login restrictions. Some examples = include:

Restricting hours of access: This means = certain users=20 are not allowed to log in at times that are pre-determined = by the=20 system administrator, for example in the middle of the = night when=20 no one is around.

Disable login on repeated invalid attempts: = This=20 prevents users (and programs) from trying to guess = passwords by=20 repeatedly attempting to log in.

Autolockscreen and logout: After a prescribed = period=20 of idle time, a workstation will automatically lockscreen = or log=20 out.

Increased controls over root/su privilege: = Requires=20 one to supply special passwords to access root and super = user=20 privileges.

Remote Access Protection

Since potentially unwanted system accesses can also be = attempted=20 over remote dial-up lines, Solaris enables modem ports to be = password protected. Once a modem port password is set, a = user who=20 dials up from a remote location will be first asked to = provide it.=20 If the correct one is supplied, the user will be allowed to = enter=20 the formal system login process.

Additional products that provide remote access protection = are=20 available for Solaris from 3rd parties. For example, = digital=20 token technology is available from companies such as = Enigma=20 Logic and Security Dynamics. A digital token is a "one time = only"=20 password that is used to control remote dial-in access. A = set of=20 pre-assigned digital tokens are stored in a hand held device = that=20 can be carried to remote locations. In this scheme passwords = are=20 never reused, resulting in tighter security.

A public domain software version of digital token = technology=20 called S/Key is also available on the Internet and = can be=20 accessed via file transfer at the following address:=20 thumper.bellcore.com /pub/nmh.

Level 2: System Resource Access = Control=20

Once a user is successfully logged in, (s)he can begin to = attempt=20 to access resources. Therefore, Solaris enables = administrators to=20 control the general accessibility of resources on the system = by=20 providing tools which can set the overall security state of = the=20 system. Solaris also offers features that enable file access = privileges to be set appropriately. In addition, auditing = capability=20 is provided to aid in tracking access attempts. These = features are=20 described in detail below.

Setting and Checking the Security = State of=20 Solaris

Most system administrators would agree that there are = times when=20 it is essential to try to assess the overall security state = of the=20 system and/or to set it appropriately. To address this, = Solaris=20 includes the Automated Security Access Tool (ASET). ASET can = automatically assess the state of the system as well as to = place it=20 in one of three pre-determined security states: low, medium, = or=20 high.

When run periodically, ASET will alert the administrator = to any=20 potential security breaches. Below is a sample of what ASET = checks=20 for:

Existence of a system EEPROM password which protects = an=20 unauthorized individual from booting the system in single = user=20 mode

Insecure use of the UMASK variable which dictates the = default=20 setting for file permissions when a file is created =

Insecure use of the PATH variable which outlines the = order in=20 which directories will be searched for a specified = executable=20 command or program

System file permission settings

Existence of new setuid programs

Home directory permissions

Contents of:.rhosts, /etc/passwd, /etc/group=20

Size of files in /usr/bin and /bin=20

Note that administrators have the option of being alerted = to=20 potential problems by electronic mail.

When used to set the system in low security mode, ASET = ensures=20 that file attributes (permissions) are set at the standard = release=20 values. Several checks are performed and any potential = security=20 weaknesses are reported.

The medium security setting provides adequate security = for most=20 environments. ASET will modify permission settings of some = system=20 files (e.g. ttytab, host.equiv) and parameters to = restrict system access. Additional security checks are = performed and=20 weaknesses and access modifications are reported.

The high security setting produces an exceedingly secure = system.=20 Many system files and parameters are set to enable only = minimum=20 access. The high security setting also can disable IP = forwarding.=20 However, this functionality has been superceded by a product = called=20 Solstice^TM FireWall-1^TM or=20 Solstice^TM SunScreen^TM from=20 Sun, covered later in this document.

With ASET, an administrator need not waste valuable time = and=20 effort manually "hunting" for security holes on the system. = ASET is=20 also a unique feature on Solaris and is not available on = other=20 system platforms.

File Protection on Solaris

Files represent a major resource that must be protected = on any=20 system platform from PCs to mainframes. Solaris implements = two=20 methods for file protection: traditional "Unix-style" = permission=20 settings and Access Control Lists (ACLs). With Unix-style = permission=20 setting, it is possible to set read, write, and execute = permission=20 indications for a file's owner, selected groups, or the = "world"=20 (also known as "other"). However, one disadvantage of = permission=20 setting is that access can only be restricted on a per-group = basis=20 and cannot single out special privilege (or restriction) for = individuals.

Support for Access Control Lists (ACLs) is in Solaris. = Access=20 Control Lists are just what the name implies: a list that = controls=20 access to files. With ACLs, extensive lists of authorization = information can be maintained for every file, enabling a = finer=20 granularity of control over file access. For example, with = ACLS=20 access can be controlled on a per-user basis in addition to = on a per=20 group basis.

Figure 2 POSIX compliant Access Control Lists on Solaris = tightly=20 control file access

ACLs on Solaris are compliant with the POSIX 1003.6=20 specification. They have been implemented for both the User = File=20 System (UFS) as well as for NFS Versions 2 and Version 3. =

Auditing

Auditing is included in this section because it helps=20 administrators track security related events including many=20 different types of access attempts. If a violation occurs, = an audit=20 log can help determine what happened and perhaps even help = discover=20 who the culprit is! Solaris includes two methods for = auditing: Unix=20 System Logs and C2 auditing. Both are discussed in this = section

Unix system logs (syslogs) keep track of login events, = resource=20 usage, quotas, and more. Many system facilities use syslogs = to=20 record or alert the system administrator to important = events.=20 Shell scripts, or wrappers, can also be = written to=20 syslog databases to cover specific situations.

C2 Auditing, also called Controlled Access Protection, = can=20 produce a more detailed audit report. The Department of = Defense=20 defined C2 auditing as part of it's guidelines for various = levels of=20 computer security in the 1980's. These requirements are = outlined in=20 the Orange Book or Trusted Computer Systems Evaluation = Criteria=20 (TC-SEC). Security levels are listed starting with D for the = lowest,=20 up to A1 for the highest. The National Computer Security = Center=20 (NCSC) evaluates systems based on this criteria.

C2 can create audit logs by user, event and class. In = addition,=20 with C2 it is possible to log any event that a system = administrator=20 deems security "relevant". Solaris C2 auditing includes the = Basic=20 Security Mode (BSM) functionality, which enables the logging = of=20 events down to the system call level.

In the unlikely event that there is a security = infraction,=20 Solaris auditing capability ensures system administrators a = detailed=20 account of relevant activity. This information can be vital = in=20 helping to track down the source of the problem.

Level 3: Secure Distributed Services = and=20 Developer Platforms

The Solaris core operating environment incorporates the = ONC+TM family of distributed services which can = optionally be configured to run with additional security = features=20 enabled. When this is the case, ONC+ consists of the Secure = NIS+=20 distributed naming service, the Secure NFS^TM=20 distributed file service, and the Secure Transport = Independent=20 Remote Procedure Call (TI-RPC) platform (also known simply = as Secure=20 RPC) for building distributed applications and services. =

Sun also provides the DCE family of services in an = unbundled=20 product called DCE for Solaris. This product = includes the=20 DFS distributed file service, the CDS distributed naming = service,=20 and the DCE RPC based developer platform (as well as other = features=20 not pertinent to this document).

Both secure ONC+ and DCE services rely on foundation = technology=20 described in this section.

Foundation Technology for Secure = Services=20

Before a user on a client system is given access to a = server's=20 resources, the server must be sure that the user is = acknowledged to=20 have "rightful" access to the server and it's resources. = Therefore,=20 in this scenario the server must be able to:

Check a user's identity over the network. This = function is=20 provided by an authentication service and also = usually=20 includes services listed in #3 below.
Make sure the user is authorized to access the = resources (s)he=20 is attempting to access once (s)he has been properly=20 authenticated. This is provided by an authorization=20 service.
Maintain the privacy and integrity of the information = being=20 exchanged over the network. These are referred to as = privacy=20 and integrity services respectively. =

Authentication, Privacy and Integrity = Services=20

Authenticating a user over the network requires that = sensitive=20 "credentials" information must be exchanged between a client = and=20 server system. Since there is no way to guarantee that this=20 information will not be intercepted as it travels to it's=20 destination, it must be protected from being interpreted or = changed=20 along the way. Thus, a secure distributed service must have = a way to=20 protect the privacy and integrity respectively of the = information.=20

Privacy and integrity services are typically bundled with = the=20 authentication service. A privacy service provides a way to = convert=20 information into a form that can only be interpreted by the = intended=20 recipient. This is also referred to as encrypting = the data.=20 The recipient is responsible for decrypting the = data or in=20 other words converting it back into a readable form. An = integrity=20 service provides a way to compute an information = checksum=20 which when examined will indicate whether the = information has=20 been altered from it's original content.

There are many authentication services both existing and=20 emerging. Therefore Solaris supports a flexible architecture = that=20 enables access to multiple authentication mechanisms both = today and=20 in the future. Currently on Solaris, authentication = mechanisms=20 including Kerberos, Diffie-Hellman and Unix-style [1])=20 are supported and are accessible via the Secure TI-RPC = interface. In=20 fact, both Secure NIS+ and Secure NFS have been developed on = the=20 Secure TI-RPC platform.

Secure DCE services on Solaris access Kerberos = authentication via=20 the DCE RPC interface. Both DFS and CDS have been programmed = to the=20 DCE RPC interface and can thus utilize the Kerberos = authentication=20 service.

Sun is currently implementing a revised authentication=20 architecture based on Internet Standard RFC 1508, also known = as the=20 Generic Security Services API (GSSAPI). The GSSAPI = unites=20 multiple authentication solutions under one API. It also = provides=20 for true "pluggable" authentication. This means that a new=20 authentication mechanisms can be plugged into the interface = without=20 affecting existing applications and services.

The term GSSRPC represents Sun's integration of = TI-RPC=20 with GSSAPI (see Figure 3) on Solaris. GSSRPC will give = RPC-based=20 applications access to multiple authentication options.

Figure 3 Internet Standard GSSAPI will = offer=20 "pluggable" authentication to support secure distributed = services on Solaris.

Pluggable Authentication Module (PAM)

Originally developed by Sun and adopted by OSF for = inclusion in=20 CDE/Motif, PAM provides a pluggable model for system = authentication=20 mechanisms as well as for other related services such as = password,=20 account, and session management. These services are = particularly=20 useful to applications providing or requiring "system entry" = (or=20 login) that must verify user identity as well as account=20 information. Some common examples of these applications = include=20 login,dtlogin,rlogin, rsh,telnet,ftp, etc.

The security mechanisms accessible through PAM are = implemented as=20 dynamically loadable, shared software modules that can be = installed=20 by administrators transparently to applications. PAM enables = the=20 administrator to configure the user authentication mechanism = on a=20 per application basis. For example, a site may = require=20 S/Key password authentication for telnet access = while=20 allowing console login sessions with just UNIX password=20 authentication. With PAM it is also possible to configure = multiple=20 authentication mechanisms for each application. For = example, an administrator may want users to get = authenticated by=20 both Kerberos and RSA. Finally, PAM enables users = of these=20 applications to supply a single password even = though=20 multiple authentication services may be in use.

GSS-API

GSS-API is a proposed standard, as defined in RFC-1508 = and=20 RFC-1509. It is becoming the de-facto standard for dealing = with=20 security services (such as authentication, integrity, and=20 encryption), in a generic, extensible fashion. Applications = can be=20 run independent of the underlying security mechanism and=20 technologies. It also allows for source level portability. =

The PAM API and GSS-API are complimentary to each other, = whereas=20 the PAM API support for user authentication by the system = entry=20 servers, GSSAPI supports network-based client/server = authentication.=20 Therefore, once users on client systems are authenticated = through=20 PAM, they can communicate securely with server systems using = GSSAPI=20 based authentication services.

Authorization Services

An authorization service or mechanism provides a way to = ensure=20 that a user has been granted permission to access the = information=20 (s)he is attempting to access remotely. NFS supports 2 = authorization=20 mechanisms: file permission indications and POSIX 1003.6 = compliant=20 ACLs. Both permissions and Access Control Lists are covered = in the=20 section entitled "File=20 Protection on Solaris". Secure NIS+ utilizes a = methodology=20 called table access rights to indicate = authorization to=20 access information stored in NIS+ tables. For more = information on=20 table access rights, please obtain the NIS+ White Paper. =

DCE DFS uses it's own ACL standard which is referred to = as DCE=20 ACLs. The DCE CDS distributed naming service makes use of = the DCE=20 ACLs as well.

Secure Remote Utilities

In addition to secure services, secure remote utilities = such as=20 telnet, ftp, rcp, rsh, and rlogin are=20 available for Solaris. These are sometimes referred to as=20 "Kerberized" utilities because they often utilize Kerberos=20 authentication.

Single Signon

A key issue in multi-vendor, distributed environments has = to do=20 with the fact that, in most cases, each host or server = requires the=20 user to provide a separate password in order to gain access = to=20 services. A method called single signon is emerging = to=20 solve this problem. With single signon, the user enters only = one=20 password to gain access to all systems in a distributed = environment.=20

Although it is only part of the solution, the PAM = interface=20 discussed in the section entitled "Authentication,=20 Privacy and Integrity Services" helps enable single = signon=20 capability due to it's ability to integrate multiple = authentication=20 mechanisms. Sun is currently developing single signon to = support=20 multiple environments such as ONC+ and DCE. The Sun Security = Manager=20 product line (add-on to Solaris) unites Solaris with various = multi-vendor environments such as Windows, IBM/MVS, VMS, = etc.

Level 4: Controlling Access to the = Physical=20 Network

Early computer networks were not designed for tight = security=20 control because it was assumed that sites (and users) = connected to=20 the network were largely trustable. Time and experience have = shown=20 that this is no longer a good assumption. In addition to = potential=20 threats from outsiders, well-intentioned internal users = might=20 accidentally expose corporate data or services from within a = network=20 to the outside world. It is therefore desirable to prevent = both=20 types of problems from occurring without requiring everyone = to=20 become security experts. Sun supports this level of service = -=20 Solaris with its unbundled Solstice FireWall-1 and=20 Solstice Sunscreen products.

Solstice FireWall-1

The purpose of a "firewall", also known as a network = security=20 system, is to ensure that all communication between the = local=20 organization's network and an external network conforms to = the=20 organization's defined network security policies. Some = examples of=20 network security policies might be "allow access to all = services=20 unless expressly denied" or "deny access to all services = unless=20 expressly allowed". Once the security policies are = established,=20 FireWall-1 can assist in implementing a network environment = based on=20 the established policies.

Figure 4 Solstice FireWall-1 implements = network=20 perimeter defense policies.

Solstice FireWall-1 is a combined hardware and software = solution=20 designed to allow or disallow packets from entering the = internal=20 network based on the established security policies. The = external=20 network is often a public network such as the Internet. = However,=20 FireWall-1 can also be used to control traffic between = different=20 departments within a local network as seen in Figure 4.

Solstice FireWall-1 combines features such as protocol = "aware"=20 individual packet screening with application-level and = circuit=20 gateways to provide an efficient, generic and secure packet=20 filtering engine. In addition to filtering technology, it = includes a=20 powerful logging and alerting system to help keep abreast of = attempted violations. Also included is an intuitive, = object-oriented=20 user interface which facilitates set up and configuration. =

Solstice SunScreen

Solstice SunScreen combines firewall functionality with = network=20 level (or IP) authentication, also known as SKIP (Simple Key = Management for IP). It is network, protocol, and application = independent. The unique "stealth" architecture of SunScreen = empowers=20 organizations with the ability to set up a virtual secure = private=20 network across public network connections such as the = Internet.=20 Because it is not a router, packets pass through without = recording=20 any indications of it's existence. Solstice SunScreen is = therefore=20 undetectable, giving potential intruders less knowledge to = exploit.=20

The Sunscreen configuration consists of a central = hardware device=20 (called SunScreen SPF-100) and a secure = Administration=20 Station from which the SunScreen security rules and = parameters are=20 specified. It allows several wires to be administered as a = single=20 network with the same range of IP addresses. This reduces = the need=20 for additional IP addresses and interfaces while providing a = central=20 place for logging and administration.

Figure 5 .Solstice Sunscreen can create a "virtual = private=20 network" across the Internet

Security Standards

Solaris supports important security standards set forth = by the=20 Department of Defense, POSIX, and the Internet community. = For=20 example:

Solaris meets the criteria set forth by the Department = of=20 Defense Orange Book for level C2 computer security = systems.=20 Solaris 2.4SE has E2/F-C2 Certification from ITSEC. = Solaris 2.6=20 E3/F-C2 ITSEC and C2 TCSEC certifications are in progress. =

Solaris UFS and NFS Version 2 and Version 3 all = support the=20 POSIX 1003.6 specification for Access Control Lists = (ACLs).=20

Internet RFC 1508, GSSAPI, is currently under = development=20

Compartmented Mode Workstation (CMW-B1) support also = known as=20 "Trusted Solaris" is currently under development for = Solaris 2.X=20

In the future Solaris will continue to encompass new and = emerging=20 security standards in response to customer requirements. =

Solaris - The Solution of Choice for = the=20 Secure Distributed Environment

There is no doubt that sophisticated security solutions = are=20 necessary in today's distributed network environment. = Solaris arms=20 corporations with tools for securing sensitive corporate = data from=20 intruders with its four levels of security: System Access = Control,=20 Resource Access Control, Secure Distributed Services, and = Physical=20 Network Protection. It adheres to the highest security = standards set=20 forth by organizations such as the Department of Defense and = POSIX=20 as well as providing the latest technology for secure public = network=20 access with unbundled products like Solstice FireWall-1 and = Solstice=20 SunScreen. A plethora of third party products complement = what is=20 available from Sun. Finally, Solaris provides flexibility = with an=20 array of choices to fulfill a wide variety of corporate = needs with=20 the ability to grow to meet tomorrow's security challenges. =

Footnotes:

[1] With Unix-style authentication, = approved=20 client systems are indicated in a list of trusted hosts.=20

Document=20 Contents:=20

-	Security:=20 A Key Issue for the Global Corporation
-	Solaris:=20 The Secure Solution
-	Level=20 1: Controlling Login Access on Solaris
-	Level=20 2: System Resource Access Control
-	Level=20 3: Secure Distributed Services and Developer=20 Platforms
-	Level=20 4: Controlling Access to the Physical = Network
-	Security=20 Standards
-	Solaris=20 - The Solution of Choice for the Secure Distributed=20 = Environment

See=20 Also:

-	Solaris=20 Security
-	Solaris 2.6=20 site
-	Network = Security=20 = Solutions

Solaris = Home | FAQs | Software = Site Map=20

SunTM SolarisTM = Security