Veil
- Version:
- 9.1.0 (Stable))
BSD
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.
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.
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 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. Changes to the underlying query engine to attempt to plug such holes have been proposed, but they all have their limitations and are likely to lead to degraded performance.
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 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.
Next: Overview: a quick introduction to Veil
