Veil is a data security add-on for the PostgreSQL relational database. 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.
The design aims of Veil were to provide a fast, efficient means of access control for data, using a relational security model within the database.
The prototype for Veil was designed for a hypothetical web-based store system. In this system, there would multiple stores at which a customer might hold an account. The stores would be managed in a hierarchy which we will call branch, regional and business. Representatives at the branch level would have access to customer accounts held at the branch. Reps at the regional level would have access to accounts at all branches in the region, and at the business level would have access to all accounts for the entire business.
The business relationships were to be managed using Len Silverton's Party Role Relationship Model (more or less). So, the business would have a relationship with each of its regional offices, they would have a relationship with each of their branches, and the branches would have a relationship with each of their customers. A company Representative would have a relationship with the business, region or branch as appropriate, and privileges would be assigned in the context of that relationship.
With me so far? I should really draw a diagram but the important point is that the rules for access to the data are relationally defined.
Because the relationships that define a Rep's privileges are rather complex, we do not want to query them repeatedly. Veil allows us to avoid this. When the rep connects to the database, their privileges in the context of each branch are calculated, once and then stored in a bitmap array. When that rep attempts to access a customer's data, we can simply identify the branch that represents that customer, and from the branch_id identify the privileges that the Rep has within the context of that branch.
So, for this rather complex, and somewhat contrived, example Veil allows us to determine a user's privileges from a complex series of relationships, with the overhead of only a single fetch (that of the customers relationship with the branch) per row. Furthermore, by caching the branch relationship for that customer, access to other data for that same customer does not even incur that single fetch overhead.
Generally, most data access will involve much less complex relationships than this. A developer will have access to project data if they have been assigned to the project. A customer will have access to their own data, always. A manager will have access to time-sheet data for staff that they manage, etc. And much of the time, access rights can be determined for a connected user with no extra fetches.
For a better understanding of Veil check out the Veil documentation pages at pgfoundry (links on the left).
If you are a SE-Linux user you may find SE-PostgreSQL to be more appropriate for your needs. The folowing paragraph is from Google's sepgsl page.
Security Enhanced PostgreSQL (SE-PostgreSQL) is an extension of PostgreSQL relational database management system, based on Security Enhanced Linux (SELinux)'s security model and policy. It can provide fine grained mandatory access control to various database objects such as tables, columns or tuples and can apply consistent authority of remote/local client integrated with operation system independent from database authorization. These facilities enable to build a database management system into information flow control scheme integrated with operating system. It helps to protect your information asset from some of threats like leaking, defacing and destruction.
The two projects have very different aims. Veil attempts to provide you with the means to define access rights based upon data relationships. It is a toolset that allows you to build your own security system. The security it provides, or fails to, will be down to the quality of your implementation. There are no guarantees.
SE-PostgreSQL is more concerned with taking the security model for SE-Linux and incorporating it into PostgreSQL. As such it will work and be secure right out of the box as long as you have properly defined your security rules.
If you need something more fleixible than SE-PostgreSQL, Veil may be right for you.
Email Marc Munro here.