Security Questionnaire for PSARC 2005/695, "CIFS Client On Solaris"

  • This Security Questionnaire is designed to collect detailed information regarding the security implications of changes to SMI's product lines.

    When answering all of the following questions please describe when an environmental security assumption is the basis for an "Not Applicable" answer.

  • Are there any security requirements documented for this project?

 

[_X_] Yes

1) Describe what version of the requirements document was used and where it can be found.
Version 1.5, at http://jurassic.eng/net/nfs-build/export1/projects/cifs/commitment.materials/cifs_client_prd.html
2) List those requirements met by the project.
All
3) Are there any specific security requirements which your project does not plan to meet?
No

[_?_] No

1) What security issues are being addressed or potentially introduced by your project.
[ answer ]

  • For each network (e.g., RPC over IP, TCP/IP, Serial, etc.) used by a project describe the following:

  • describe the protocol stack being used
    /dev/nsmb pushes TCP/IP below it and implements a NetBIOS initiator.

  • list the service/application to which this project will communicate and the mechanism used (if IP based list static/dynamic ports used)
    The CIFS client will talk to WINS/NetBIOS servers via TCP port 139, CIFS servers over TCP ports 137 and perhaps 445 ("direct TCP").

  • describe what information will flow and/or be made available over this network connection
    Various dialects of the SMB/CIFS protocol will be sent to and received from the server in order to access files on SMB/CIFS shares.

  • describe how each network service that is created, installed, used or depended upon is compliant with the Network Install-Time Security policy defined in: http://sac.eng/swg/Security/Policy/NITS.html

  • Specifically, how does each outbound service meet the protection requirements using: SVC1, SVC2, or SVC[3,4] including how OUT[1-3] protection is enforced.
    SVC2 - no install time usage and no automatic usage after install

  • Specifically, how does each inbound service meet the protection requirements using: SVC1, SVC2, or SVC[3,4] including how IN[1,2] protection is enforced.
    N/A

  • How are the other aspects of the policy met (e.g. warning about install options which are non-compliant to administrator?)
    N/A

  • Describe how to disable each network service from your project and the side effects (e.g. dependencies) of doing so.
    For complete security, our packages may be removed (SUNWsmbfs{r,u}).

  • For each network service, discuss how it protects its communications from network-based: theft, replay, content change and user impersonation within the following sub-sections:

  • Does your service make decisions based on user, host or service identities?

[_?_] Yes

1) Describe how your project authenticates or discover the host, user, or services identity?
Server names may be retrived via gethostbyname() or via the NetBIOS Name Service (NBNS, aka WINS); identities are not strongly authenticated unless Kerberos is configured.
User names are retrieved via getXbyY() calls and are authenticated by the server.
2) If authentication is done by another component explain how you obtain this information and why you believe its authentic.
CIFS "sessions" can be authenticated by Kerberos if configured.
3) If your project authenticates, explain the authentication process including any standards or existing components used.
Section 6 of our Design Document (http://jurassic.eng/net/nfs-build/export1/projects/cifs/commitment.materials/CIFS_Design_Doc.html) covers the various authentication models supported by the client. Broadly, it can use a few variants of password-based authentication or it can use Kerberos-based authentication.
4) In addition, describe what happens if the authentication process fails.
If the client does not have a password to use with password-based authentication, mounts will not be successful.
5) If passwords or passphrases are used, discuss how they are protected from host or network-based theft, protected if stored beyond authentication, how they can be changed, and any validity checking which occurs.
To communicate with CIFS servers using passwords, the passwords are generally encrypted, but some encryption methods are known to be weak.

[_?_] No


  • Does your project make decisions about whether a requestor may access a particular resource?

[_X_] Yes

Explain how this occurs for both successful and unsuccessful access requests.
In the absence of a password for a user/server tuple, mounts will fail.

[_?_] No


  • Does your project protect its communications from passive listeners on the network?

[_?_] Yes

Explain the techniques used to accomplish this.
[ answer ]

[_X_] No

Explain why not.
The product can use Kerberos for authentication and possibly integrity; packet encryption is just starting to be deployed in the CIFS world, but our code base does not support it.

  • Describe how network-based access control is provided
    (e.g., this could be provided through technologies such as host-based firewalls/IPsec or application-level controls such as TCP Wrappers).
    N/A

  • Does your service protect the integrity of its communications over the network?

[_?_] Yes

Explain the techniques used to accomplish this.
[ answer ]

[_?_] No

Explain why not.
The product can use Kerberos for authentication; integrity (packet signing) is widely used with CIFS in recent versions of Windows, and we will try to support it for our first release.

  • Describe how this network communication is protected against replay attacks in which a partial record of an earlier network exchange is replayed
    The NTLM and NTLMv2 challenge/response algorithms requires that the client compute the hash of a "random" challenge (chosen carefully by the server) that prevents replay attacks. Packet signing (integrity) can also be used (see above).

  • Describe how your network communications could be exploited by a denial of service (DoS) attack.
    (For instance, what resources are allocated during session setup before the requestor has been authenticated)
    N/A

  • Does this project use secret information (e.g. passwords, passphrases, PINs or equivalent authenticators) during authentication and/or authorization?

[_X_] Yes

  1. Describe all methods for how this secret information can be obtained (e.g. user prompted interactively.)
    The user can put a password on the 'smbutil' command line or be prompted for it with 'smbutil login'.

  2. If the secret information can be obtained via command line or environment variable, explain how the project complies with the SAC Reusable Passwords policy at:
    http://sac.eng/swg/Security/recommendations/reusable_password_policy_v1.0.txt
    N/A

  3. If the secret information can be obtained from persistent storage (e.g. file), explain how the storage is protected and compliant with the SAC Storing Reusable Passwords policy at: http://sac.eng/swg/Security/recommendations/SecSWG_Policy_ReusablePW_FS_v1.0.txt
    Passwords for password-based schemes are stored in kernel memory managed by the nsmb device driver.

  4. Describe how the secret information is: created, provisioned, updated, revoked, and checked for policies regarding its content (e.g. password strength checks.)
    'smbutil login' adds or updates stored passwords, and 'smbutil logout' removes them.

  5. How is this secret information expunged from the project's memory after use (e.g. so it doesn't appear in core files?)
    Plain-text passwords can be visible in kernel crash dumps.

[_?_] No


  • Does a non-privileged (e.g., not having access equivalent to uid 0 on pre-RBAC/Least Privilege OEs) user have access to all project functionality?

[_X_] Yes

Describe why there are no potential RASS (Reliability, Availability, Serviceability, and Security) reasons to restrict non-privileged access.
Share listings are unrestricted by the client functionality. For mounting, we want to grant SYS_MOUNT to users of the /usr/lib/fs/smbfs/mount and ensure that non-root users can only mount on directories which they own.

[_?_] No

Describe how/where authentication and authorization checks are done.
[ answer ]
List the roles, rights, and authorizations needed to access the functionality included in this project.
[ answer ]
Does your project perform authorization checking itself or does it use another component? If itself, explain how this occurs and why this project has its own authorization system.
[ answer ]

  • Except for networking (discussed above), does this project use cryptography for any purpose?

[_X_] Yes

  1. For each use of cryptography in this project, describe the algorithms, key sizes and design for how it is being used.
    If any non-standard cryptographic algorithms or protocols are used, describe why that algorithm and protocol was selected.
    The CIFS client can use 56-bit DES, MD4 (RFC 1320) and HMAC-MD5 (RFC 2104) to encrypt passwords and challenge/response exchanges; typically a password derivative is used as the encryption key for a well-known piece of text. For further information, see http://www.ubiqx.org/cifs/SMB.html#SMB.8.

  2. For each use of cryptographic keys or certificates specify:

  3. what types of keys and/or certificates are used,
    N/A

  4. what they are used for,
    N/A

  5. how they are created, updated, and deleted,
    N/A

  6. where they are stored, and
    N/A

  7. what the secure backup and recovery method is.
    N/A

  8. Export classification:

  9. What crypto export classification will the project and product have?
    This project exports no crypto APIs. Export control has signed off on our outbound Open Source Request review, at https://opensourcereview.central.sun.com/app?action=ViewReq&traq_num=6094.

  10. For projects and products with a non-retail crypto export classification, what design features are incorporated to allow for the substitution of a cipher which has retail approval.
    [ answer ]

[_?_] No


  • Is any privileged user or group account (e.g., suid root, or other privileged setting mechanism) software part of your project?

[_?_] Yes

Describe how the principle of least privilege (e.g. daemon dropping privileges once no longer needed) has been applied.
[ answer ]
In addition, list all privileges required for this software.
[ answer ]

[_X_] No


  • Are any log, error, FMA, or audit events generated?
    Note - this question applies to all auditing mechanisms, whether implemented in Solaris auditing, J2SEs logging facility, or Windows event logging

  • We will use cmn_err() to log errors in the same way NFS uses it, with CE_NOTE, CE_CONT, CE_WARN and CE_PANIC as appropriate. Since the actual resources being served are not local, FMA does not seem a fit here.

[_?_] Yes

  1. List all security error events that may be generated and their causes.
    [ answer ]

  2. Will this project generate any audit records?

[_?_] Yes

List those events for which you will generate audit records. [ answer ]

[_?_] No

Describe why not.
[ answer ]

[_X_] No


  • Will this project run on Solaris?

[_X_] Yes

What is the smallest sized Solaris installation Meta Cluster (e.g. Solaris 10 "Reduced Networking" (PSARC 2002/254)) on which it has been tested?
The End User metacluster,
If it will not run on the Reduced Networking Meta Cluster, what additional packages are necessary? Are these included in the appropriate package dependency files?
Unknown at this time

[_?_] No


  • Will the project undergo a security evaluation/certification by itself or as part of a larger product (e.g. Solaris releases are certified against the Common Criteria's CAPP at EAL4)?

[_X_] Yes

  1. Against which standards will it be evaluated?
    [_?_] Common Criteria: which protection profiles (e.g., CAPP) and to what assurance level (e.g., EAL4)? CAPP at EAL4 as part of Solaris
    [_?_] FIPS 140-2: what level (1 to 4) is the evaluation? [ answer ]
    [_?_] Other: Provide specific details [ answer ]

  2. What already-evaluated mechanisms (e.g., auditing) will your project be using to make this possible and as simple as possible?
    [ answer ]

  3. What already-evaluated mechanisms was your project not able to leverage and why?
    [ answer ]

[_?_] No


  • How does the project provide for failsafe defaults such that the security is not compromised?
    (For example, how does the project ensure that the security of the product isn't compromised by corrupted or missing configuration files)
    Our “minauth” setting defaults to demanding NTLM, which has acceptable strength for most security environments. Without proper configuration information, the client will be unable to negotiate a session properly with the server.