Security Questions -------------------- sosd: SCSI Object-based Storage Device Driver The project provides object device support to Solaris. It exports an interface through which clients (typically filesystems) can send T10 OSD commands to a storage device. The interfaces into the driver are: - scsi_osd (kernel client) - libsosd (user client) - uscsi ioctl (user client) The kernel client interface requires that the caller have SYS_DEVICES privilege to be able to open and operate on the device. The project uses existing access control profiles to authorize usermode clients. The usermode client's role should have 'Device Management' and 'Device Security' profiles. Additionally if the client is a general purpose filesystem utility, it may also choose to have 'File System Management' and 'Object Access Management' profiles in its role. The initial intended use of the API is over iSCSI transport. So, IP network security mechanism such as IPSEC and authentication mechanism like CHAP and RADIUS automatically provide transport level security. 1. Are there any security requirements documented for this project? [X] No a. What security issues are being addressed or potentially introduced by your project. No specific security requirements are documents. The driver follows RBAC security model described above. 2. For each service that is created, installed, used, or depended upon, describe, how it is compliant with the Install-Time Security Policy ( http://sac/cgi-bin/bp.cgi?NAME=ITS.bp and/or http://www.opensolaris.org/os/community/arc/policies/ITS/ a. 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 level is met using RBAC. The driver is not loaded unless a object device is configured to be enumerated by this client. Assuming that an "outbound" receiver is the object device itself, outbound service levels are met through transport level security. The project relies on HBA drivers to authenticate the device and encrypt communication (as necessary) before putting data on the wire. b. 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. SVC2 level is met using RBAC. The driver is not loaded unless a object device is configured to be enumerated by this client. Assuming that an "inbound" sender is a filesystem (or random client) trying to access the device IN1 is achieved by creating the minor node with permissions "0640 root sys" IN2 is acheived by authorizin client first during open, and also authenticating client requests on all API calls. The project relies on RBAC to provide support. c. How are the other aspects of the policy met ( e.g., warning to the administration about install options which are non-compliant) N/A d. Also, list the service/application to which this project will communicate and the mechanism used (if external network interfaces are used, or the connection uses purely local interconnects, and if IP based list static/dynamic ports used) No external network interfaces. 3. Describe how to disable each service from your project and the side effects (e.g. dependencies) of doing so. No (smf) services are introduced by the project. Assuming the API is a service, the service unloads when there are no outstanding opens (and no pending commands). Forcible API service denial for authenticated and misbehaving clients is not possible. 4. For each service, discuss how it protects its communications from: theft, replay, content change and user impersonation within the following sub-sections: a. Does your service make decisions based on user, host or service identities? [X] No b. Does your project make decisions about whether a requestor may access a particular resource? [X] No c. Does your project protect its communications from passive listeners on the network? [X] No Explain why not. These communications will be handled by transport level security as the driver does not know (and shouldnt care about the HBA and the medium) d. Describe how host and network-based access control are provided (e.g., this could be provided through technologies such as host-based firewalls/IPsec or application-level controls such as TCP Wrappers). HBA drivers provide this. A good example is iSCSI, which provides CHAP/RADIUS for authentication and and IPSEC for IP layer security. e. Does your service protect the integrity of its communications over the network? [X] No Explain why not. The driver has no role to play in network communication. f. Describe how network communication is protected against replay attacks in which a partial record of an earlier network exchange is replayed N/A g. 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 5. For each network (e.g., RPC over IP, TCP/IP, Serial, etc.) used by a project describe the following: a. describe the protocol stack being used Any network stack in Solaris that can support SCSI protocol. b. describe what information will flow and/or be made available over this network connection. Protocol related Management and data commands. 6. Does this project use secret information (e.g. passwords, passphrases, PINs or equivalent authenticators) during authentication and/or authorization? [X] No. 7. Describe how the project uses the file system in a way that is compliant with the FILE SYSTEM GUIDANCE section of the Install-Time Security Policy (see above) for cases other than storage of secret information (previous question). FS1 - Files are created with root/sys root/bin permissions. FS2 - Project does not have sensitive data files. FS3 - Wont use setuid/setgid bits. Uses RBAC. FS4 - Uses existing root/sys root/bin uid/gid. FS5 - Directories are created with root/sys permissions. FS6 - No inheritable directories. FS7 - Directories use existing root/sys permission. 8. 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] No a. Describe how/where authentication and authorization checks are done. RBAC policy is enforced for user client access. SYS_DEVICES privilege is enforced for kernel client access. b. List the roles, rights, and authorizations needed to access the functionality included in this project. The project uses existing access control profiles to authorize usermode clients. The usermode client's role should have 'Device Management' and 'Device Security' profiles. Additionally if the client is a general purpose filesystem utility, it may also choose to have 'File System Management' and 'Object Access Management' profiles in its role. c. 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. Uses RBAC and drv_priv() 9. Except for networking (discussed above), does this project use cryptography for any purpose? [X] No 10. Is any privileged user or group account (e.g., suid root, or other privileged setting mechanism) software part of your project? [X] No 11. 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 [X] Yes a. List all security error events that may be generated and their causes. The project will generate error and log information through the scsi_log(9F) interface. A object oriented interface equivalent to scsi_errmsg(9F) called sosd_errmsg() will be used but it is nto exported. b. Will this project generate any audit records? [X] No 12. 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] No 13. 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) The configuration file is only for tunable parameters, none of which exist now. The project provides same default minor permissions as the scsi disk driver (sd) and outgoing communications will be through the scsi_vhci minor node for mpxio enabled devices.