mirror of
https://git.proxmox.com/git/mirror_corosync
synced 2025-10-30 05:14:44 +00:00
89 lines
3.4 KiB
Plaintext
89 lines
3.4 KiB
Plaintext
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
|