9.1.0 (Stable))




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:

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. 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 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

Next: Overview: a quick introduction to Veil

Generated on Mon Sep 12 15:57:51 2011 for Veil by  doxygen 1.5.6