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? The project includes an implementation of STP. Hacking into STP would give an attacker the ability to disable bridge ports within the network. (Anyone who has DLPI access necessary to hack STP already has the ability to do this with existing bridges and switches in the network.) Damaging or disabling STP can result in persistent forwarding loops that melt the network. The bridging service is not enabled by default, but when it is enabled, STP is used by default. The bridging daemon has a door-based interface that provides read-only statistics for display. The control and configuration of the daemon is exclusively through SMF/SCF and dladm/dlmgmtd. 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. We use SVC2 (not enabled by default). For OUT1-3, there essentially is no protection other than physical access: the standards mandate that bridges must not forward BPDU frames, and thus you need direct access to the physical ports in order to inject your own frames. This is all governed by IEEE standards; we have no flexibility here whatsoever. 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. IN1-2 cannot be accomodated in any way other than physical security, per the standards. In fact, restricting the BPDUs in any way is itself a risky proposition for the network: STP fails "open." It's the opposite situation from ordinary TCP/IP communications. c. How are the other aspects of the policy met ( e.g., warning to the administration about install options which are non-compliant) We minimize the privileges required to install and run the service. There are no additional files or directories involved. There are no install options other than the documented STP parameters, and the defaults for those are set by the standards. c. 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) We use bridging PDUs, a MAC level service. These are physical-link-local, and have nothing to do with TCP/IP. Routers and hosts generally ignore bridging PDUs. Bridges are required to filter them out of the forwarding process. 3. Describe how to disable each service from your project and the side effects (e.g. dependencies) of doing so. You can disable bridging (it's disabled by default) and separately disable STP if desired. If you turn off STP on a port (link), then loop protection becomes your problem. In order to avoid accidents, we monitor ports with STP disabled for bridging PDUs. None should ever be seen. If one is, then we disable forwarding on that port and log an error. 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] Yes Explain how this occurs for both successful and unsuccessful access requests. The kernel 'bridge' interfaces check for PRIV_SYS_NET_CONFIG before allowing any change to the system configuration. c. Does your project protect its communications from passive listeners on the network? [X] No Explain why not. The standards don't allow for it, and doing so would make the system much less secure. (This seems like a TCP/IP-centric question.) 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). No access control is provided or could be provided. e. Does your service protect the integrity of its communications over the network? [X] No Explain why not. The standards afford us only CRC-32 on the MAC frame itself and simple (and obvious) checks on the PDU contents. No more robust checks (such as cryptographic methods) are possible in any standards-conformant manner. f. Describe how network communication is protected against replay attacks in which a partial record of an earlier network exchange is replayed. It cannot. 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) A user with physical access and the ability to send BPDU frames could emulate an arbitrary number of bridges, send a flood of BPDU datagrams, and otherwise disrupt the network. Bridges are like that. 5. For each network (e.g., RPC over IP, TCP/IP, Serial, etc.) used by a project describe the following: 1. describe the protocol stack being used Spanning Tree over IEEE Bridging PDUs 2. describe what information will flow and/or be made available over this network connection Layer two topology and STP control information are sent via BPDUs. 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). It doesn't use the file system. 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. dladm and svcadm are the standard administrative interfaces, and checks for authorization are made in dlmgmtd and configd. b. List the roles, rights, and authorizations needed to access the functionality included in this project. Administrative rights are available to "Network Administrator" for the configuration parameters. Service enable/disable is controlled by the solaris.smf.modify authorization. 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. The main checking is in dlmgmtd and configd. The bridging kernel component protects itself against unauthorized changes (ioctls) by checking for PRIV_SYS_NET_CONFIG. 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. N/A - just debug logs b. Will this project generate any audit records? [X] No Describe why not. Existing audit logs for dladm and svcadm should be used. 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)? N/A - part of Solaris 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) It doesn't run by default. When enabled by an administrator, it uses STP to protect the network against loops by default. The kernel components are designed such that if the STP daemon goes down for any reason, all forwarding is torn down to protect the network. The standard IEEE multicast range 01:80:c2:00:00:0x is never forwarded; these are bridging and MAC control frames.