SECURITY: Remove SECURITY file

Basically no information from SECURITY file is valid.

Library interface and related uidgid are better described in manpages.

LibNSS is not directly used any longer.

Signed-off-by: Jan Friesse <jfriesse@redhat.com>
Reviewed-by: Christine Caulfield <ccaulfie@redhat.com>

SECURITY

@@ -1,88 +0,0 @@
-Security Design of corosync
-
-The corosync project intends to mitigate the following threats:
-
-1. forged group messaging messages which are intended to fault the corosync
-   executive
-2. forged group messaging messages which are intended to fault applications
-   using corosync apis
-3. monitoring of network data to capture sensitive information
-
-The corosync project does not intend to mitigate the following threats:
-
-1. physical access to the hardware which could expose the private key
-2. privledged access to the operating system which could expose the private key
-   or be used to inject errors into the corosync executive.
-3. library user creates requests which are intended to fault the corosync
-   executive
-
-The corosync project mitigates the threats using two mechanisms:
-
-1. Authentication
-2. Secrecy
-
-Library Interface
------------------
-The corosync executive authenticates every library user.  The library is only
-allowed to access services if it's GID is corosync or 0.  Unauthorized library
-users are rejected.
-
-The corosync group is a trusted group.  If the administrator doesn't trust the
-application, it should not be added to the group!  Any member of the corosync group
-could potentially send a malformed request to the executive and cause it to
-fault.
-
-Group Messaging Interface
--------------------------
-Group messaging uses UDP/IP to communicate with other corosync executives using
-messages.  It is possible without authentication of every packet that an
-attacker could forge messages.  These forged messages could fault the corosync
-executive distributed state machines.  It would also be possible to corrupt
-end applications by forging changes.
-
-Since messages are sent using UDP/IP it would be possible to snoop those
-messages and rebuild sensitive data.
-
-To solve these problems, the group messaging interface uses two new interfaces
-interal to it's implementation:
-1. encrypt_and_sign - encrypts and signs a message securely
-2. authenticate_and_decrypt - authenticates and decrypts a message securely
-
-When the executive wants to send a message over the network, it uses
-encrypt_and_sign to prepare the message to be sent.  When the executive
-wants to receive a message from the network, it uses
-authenticate_and_decrypt to verify the message is valid and decrypt it.
-
-Corosync uses AES256/SHA-1 which from the Mozilla Network Security
-Services (libnss) library.
-
-The internal functions utilize the following algorithms:
-sha1 - hash algorithm secure for using with hmac
-hmac - produces a 16 byte digest from any length input
-
-Every message starts with a
-struct security {
-	unsigned char digest[20]; A one way hash digest
-	unsigned char salt[16]; A securely generated random number
-}
-
-USING LIBNSS
-------------
-When corosync is started up libnss is initialised,
-the private key is read into memory and stored for later use by the code.
-
-When a message is sent (encrypt_and_sign):
-------------------------------------------
-- The message is encrypted using AES.
-- A digest of that message is then created using SHA256 and based on the
-  private key.
-- the message is then transmitted.
-
-When a message is received (decrypt_and_authenticate):
-- A Digest of the encrypted message is created using the private key
-- That digest is compared to the one in the message security_header
-- If they do not match the packet is rejected
-- If they do match then the message is decrypted using the private key.
-- The message is processed.
-
-Comments welcome mailto:users@clusterlabs.org