4.15. Security¶

4.15.1. Privileges¶

quasardb does not need administrative privileges. Running the daemon as an account with administrative privileges is strongly discouraged.

quasardb only needs the following privileges:

• The ability to listen on a TCP port. The default port is 2836.
• Read and write-permission on the hard drive to persist entries. The default location is ./db/.
• Read and write-permission to its log files, if enabled. Log files are disabled by default.

For more information on how to change the quasardb daemon configuration for your environment, see quasardb daemon.

4.15.2. Authentication¶

QuasarDB has a built-in authentication mechanism based on asymetric cryptography. The performance impact of authentication on performance is negligible for the great majority of use cases.

Authentication only implies the exchange of small messages between the client and the server at the establishment of the connection.

..note::
The key exchange algorithm used is X25519. Authentication is made using Poly1305 MAC. The implementation is based on libsodium.

When configuring a cluster, the administrator must generate a long-term cluster key pair that will be reused for the nodes within the cluster, the public key part will be used by the clients connecting to the cluster, whereas the secret key should only be kept on the server and must never be communicated to any client (see quasardb cluster key generator).

The admnistrator then must add users to the cluster (see quasardb user adder). Users cannot chose their password, instead, they will receive a security token they must use to authenticate to the cluster. This security token must not be shared with anyone and be kept safe.

The server does not need to keep a copy of this security token, meaning that if the user list is stolen, it cannot be used to connect to the server.

It is possible to completely disable security and authentication, for example for test clusters or clusters running in physically secure environments.

4.15.3. Privileges¶

Each user is assigned a combination of default privileges. The default privileges will be used to determine if an user is allowed to execute a command against an object.

For example, an user with only the select privilege will not be able to insert rows into a table, unless additional privileges have been granted to that user for that table.

In addition to the priviliges, an user may be flagged as “superuser”. A superuser will ignore all permissions and can run all the commands on all the objects.

The default privileges are entered when the user is added to the cluster (see quasardb user adder).

When the default privileges are updated, the user needs to reconnect for the changes to take effect.

4.15.4. Internal cluster communications¶

When the cluster security is enabled, exchange between the nodes have the same security level as exchanges with the clients:

• When authentication is enabled, nodes will authenticate themselves using the cluster key pair and the built-in username “>[HAL_9000]<”.
• When stream encryption is enabled, communications between the nodes will also be encrypted.

The builtin user “”>[HAL_9000]<” has superuser privileges and cannot be disabled. This is why securing the cluster key pair is of the outmost importance.

4.15.5. Access control¶

In addition to default privileges, you can specify access control for every entry. The explicit access specification overrides the default privileges of the user.

You can use access control to:

• Give more access than the default privileges
• Give less access than the default privileges

Modifying access control requires the “set_acl” privilege.

To give explicit privileges to an entry use the GRANT query (see Grant) to remove privileges use the REVOKE query (see Revoke).

To improve performance, nodes will cache ACL information. The size and duration of the cache is configuration. This means that it may take up to the cache date validity for updated ACL information to propagate in the cluster.

4.15.6. Disabling an user¶

To disable access for an user entirely, set the disabled flag to “true”. The user will no longer be able to login, regardless of its privileges.

4.15.7. Traffic encryption¶

QuasarDB has built-in support for full traffic encryption as well as message integrity. Traffic encryption requires authentication to be turned on.

Note

Traffic is encrypted using AES GCM with a 256-bit key. It requires the AES-NI instructions or equivalent. Thus, it is not available on all platforms.

Because traffic encryption can have a significant performance impact, it is turned off by default.

4.15.8. Perfect forward secrecy¶

The QuasarDB security protocol provides perfect forward secrecy by default. This means that communications recorded in the past cannot be decoded should any of the long-term private keys be compromised.

Each client connecting to the cluster uses a two phase authentication where a temporary, short-term key pair is generated and exchanged using the long-term keys to generate a symmetric session key.

4.15.9. Denial of Service (DoS) protection¶

The quasardb protocol, especially the serialization layer, has been designed to resist buffer overflows and most of current denial of service (DoS) attacks. Keep in mind, however, that quasardb is designed to accept large amounts of requests or arbitraty sizes and will therefore not limit incoming or outgoing requests in any way.

QuasarDB limits on the client and on the server the maximum message size that is allowed to be transmitted by setting a maximum value to the network buffers size. The default value is 25 MB. Because of protocol compression, larger amounts of data may be allowed to go through the network in one message. This value is configurable (network buffer sizes) and needs to be changed both in the server and in the client to transmit larger messages (see quasardb daemon and C).

There is no limit to the configurable maximum message size, however excessively large values may cause out of memory errors.

4.14. Backing up quasardb
5. Application Reference