Page MenuHomeClusterLabs Projects
Files F4512161

No OneTemporary
Actions

View Options

diff --git a/SECURITY b/SECURITY
deleted file mode 100644
index b068648f..00000000
--- a/SECURITY
+++ /dev/null
@@ -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

File Metadata

Mime Type
text/x-diff
Expires
Wed, Jun 25, 4:25 AM (1 d, 10 h)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
1952139
Default Alt Text
(3 KB)

Event Timeline