Version: 9.5.0 (Stable))

License

BSD

Introduction

Veil is a data security add-on for Postgres. It provides an API allowing you to control access to data at the row, or even column, level. Different users will be able to run the same query and see different results. Other database vendors describe this as a Virtual Private Database.

Why do I need this?

If you have a database-backed application that stores sensitive data, you will be taking at least some steps to protect that data. Veil provides a way of protecting your data with a security mechanism within the database itself. No matter how you access the database, whether you are a legitimate user or not, you cannot by-pass Veil without superuser privileges.

Veil Advantages

By placing security mechanisms within the database itself we get a number of advantages:

Ubiquity. Security is always present, no matter what application or tool is used to connect to the database. If your application is compromised, your data is still protected by Veil. If an intruder gets past your outer defences and gains access to psql, your data is still protected.
Single Security Policy and Implementation. If you have N applications to secure, you have to implement your security policy N times. With Veil, all applications may be protected by a single implementation.
Strength in Depth. For the truly security conscious, Veil provides yet another level of security. If you want strength in depth, with layers and layers of security like an onion, Veil gives you that extra layer.
Performance. Veil is designed to be both flexible and efficient. With a good implementation it is possible to build access controls with a very low overhead, typically much lower than building the equivalent security in each application.
Cooperation. The Veil security model is designed to cooperate with your applications. Although Veil is primarily concerned with data access controls, it can also be used to provide function-level privileges. If your application has a sensitive function X, it can query the database, through Veil functions, to ask the question, "Does the current user have execute_X privilege?". Also, that privilege can be managed in exactly the same way as any other privilege.
Flexibility. Veil is a set of tools rather than a product. How you use it is up to you.

Veil Limitations

Veil can restrict the data returned by queries but cannot prevent the query engine itself from seeing restricted data. In particular, functions executed during evaluation of the where clause of a query may be able to see data that Veil is supposed to restrict access to.

As an example let's assume that we have a secured view, users, that allows a user to see only their own record. When Alice queries the view, she will see this:

select * from users;

  userid  |   username
----------+-----------
   12345  |   Alice

Alice should not be able to see any details for Bob or even, strictly speaking, tell whether there is an entry for Bob. This query though:

select * from users 
where 0 = 9 / (case username when 'Bob' then 0 else 1 end);

will raise an exception if the where clause encounters the username 'Bob'. So Alice can potentially craft queries that will enable her to discover whether specific names appear in the database.

This is not something that Veil is intended to, or is able to, prevent.

A more serious problem occurs if a user is able to create user defined functions as these can easily provide covert channels for leaking data. Consider this query:

select * from users where leak_this(username);

Although the query will only return what the secured view allows it to, the where clause, if the function is deemed inexpensive enough, will see every row in the table and so will be able to leak supposedly protected data. This type of exploit can be protected against easily enough by preventing users from defining their own functions, however there are postgres builtins that can be potentially be exploited in the same way.

The Good News

The news is not all bad. Although Veil can be circumvented, as shown above, a database protected by Veil is a lot more secure than one which is not. Veil can provide extra security over and above that provided by your application, and in combination with a well designed application can provide security that is more than adequate for most commercial purposes.

Veil Documentation

Better News

In the latest versions of PostgreSQL, some improvements have been made in the area of security, particularly with respect to security functions and ensuring that untrusted functions may not leak data that should be hidden.

Note that there are likely to be costs associated with some of these improvements, as the query engine will apply untrusted functions later in the query execution plan. If those untrusted functions are used to significantly reduce the size of a dataset, moving their execution to later in the plan may have an adverse effect on performance. For this reason, you should test and benchmark and decide for yourself whether there is a performance hit, and whether the value of improved security is worth any measured loss of performance.

You are also advised to follow the progress of Row Level Security support in later versions of Postgres, as this may obviate your need for Veil, or change the way in which you will use it.

Next: Overview: a quick introduction to Veil