Kdb User Permissions Security

Out of the box kdb provides severely limited authentication and access controls. It is up to the user to modify the default setup to satisfy these requirements when needed. We will consider typical security requirements and how we can implement them.

Default Kdb Security

Command Line kdb Options

Kdb provides a number of command line options for restricting access, these include:

-U	Specify a username / password file that contains the list of permitted users and their passwords.
-u	Same as -U however further restricted that q process can not access files above it's current directory.
-b	Connected clients cannot write to the database, for them it is read only.
-T	Enforce a timeout in seconds on all client queries.

Using -u to Password Protect Access

Here we demonstrate protecting a kdb server using an md5 encrypted password file. Notice the client process cannot open a connection without specifying the correct username and password as set in our file.

Server q -u userpass.txt -p 5000 q) q)\\ q -u userpass2.txt -p 5000

Client q)h:hopen `::5000 'access q)h:hopen `::5000:ryan:wrongpass 'access q)h:hopen `::5000:ryan:pass1 q)h "2+2" 4 q)/ we can read the password file q)h "read0 `:userpass.txt" "ryan:pass1" "arthur:pass2" q)h:hopen `::5000:ryan:baad 'access q)h:hopen `::5000:ryan:pass1 q)h "read0 `:userpass2.txt" "ryan:a722c63db8ec8625af6cf71cb8c2d939" "arthur:c1572d05424d0ecb2a65ec6a82aeacbf"

When running with -u it also restricts what files can be accessed, which system commands can be run. However as demonstrated in the video, these can be worked around by a malicious user for example by overriding the timer .z.ts function to run the commands as console.

Server started with "q -u ../userpass.txt -p 5000". Then from client call:

q)h:hopen `::5000:ryan:pass1 / some commands do not work q)h "\\cd" "C:\\temp\\cc\\kdb-security-user-permissions\\rundir" q)h "\\echo \"a\" >> b.txt" 'access / malicious user can override timer, and run commands as console q)h "read0 `:../userpass.txt" 'access q)h ".z.ts:{a::read0 `:../userpass.txt;}" q)h "\\t 1000" q)h "a" "ryan:pass1" "arthur:pass2"

Customized Authentication using .z.pw

Event Handlers

The second feature kdb exposes for handling security are event handlers. You can override special functions to handle authentication and client calls. These would allow denying users access on an extremely customizable level. important event handlers include:

.z.pw	PassWord authentication. First arg is username symbol, second is password string.
.z.pg	Synchronous or Get call handler, x argument is the incoming message.
.z.ps	Asynchronous or Set call handler, x argument is the incoming message.
.z.po	Port Open, called when a new connection is made.
.z.pc	Port Close, called when an existing connection is closed.

Complete details on kdb event handlers and a video guide to using them are available on the IPC tutorial.

As you can see kdb provides extremely powerful hooks into their system to implement security but it is very much up to you to write that code.

Basic Example of .z.pw

Server q -p 5000 q).z.pw:{show x; show y; 1b} `ryan "pass1" q).z.pw:{(x~`ryan) and y~"pass1"}

Client q)h:hopen `::5000:ryan:pass1 q)h:hopen `::5000:ryan:pass1 q)h:hopen `::5000:ryan:pass23 'access

Try tunning user-table.q as the server script, to see an example of having a user table to control access using .z.pw

Restricting what commands a user can run

Our example file restricted-querys.q allows running a server that restricts users to only running selected functions.

Server q restricted-querys.q -p 5000 q)user name funcs pass .. -----------------------------------.. ryan ``getTrades 0xa722c63db8ec86.. arthur `getStocks 0xc1572d05424d0e..

Client q)h:hopen `::5000:ryan:pass1 / cant remotely call string format query q)h "2+2" 'noStringQry / cant call the getStock function as user not entitled q)h (`getStock;`C) 'notPermitted / getTrades is permitted for user ryan q)h (`getTrades;2015.01.01;`C) dt sym price size ------------------------- 2015.01.01 C 10 10

Authentication, Authorization and Accounting

AAA is a common acronym in computer security that refers to:

1. Authentication - the process where an entity's identity is authenticated, for example requiring a secret password.
2. Authorization - Checking whether a particular entity is authorized to perform a given activity, i.e. user permisions
3. Accounting - Tracking resource usage.

In this tutorial we covered

1. How to authenticate users in kdb+ using a password file or by overriding .z.pw.
2. That event handlers could be overridden to provide authorization controls.
3. The last area, accounting we did not touch in this article, commonly this is implemented at the OS level or by command line options to restrict resources. Accounting can also include auditing which means logging all calls/connections by users. This topic will be covered more in other areas of the course.

You should know have a much better knowledge of how to implement security to control user access wthin kdb+.

Latest Functional in kdb+ 3.4

The latest versions of kdb include new functionality useful for security:

• SSL - can use both incoming and outgoing encrypted connections using Secure Sockets Layer(SSL)/Transport Layer Security(TLS). .
• reval - Read-only eval of parse tree. The new keyword reval, backed by -24!, behaves similarly to eval (-6!), but evaluates the parse tree in read-only mode, as if the cmd line option -b were active for the duration of the reval call. This should prove useful for access control.