Re: SE-PgSQL patch review

On Thu, Nov 26, 2009 at 11:15:46AM +0900, Itagaki Takahiro wrote:
> ==== No interaction with existing features ====
> * SE-PgSQL injects security-context-based access control, but there are
> no interaction between it and the existing role-based access control.

And there shouldn't be, I think. SE-PgSQL is MAC which means that what
someone can access is configured elsewhere. This example is
non-sensical:

> =# ALTER ROLE role VALID ON SECURITY CONTEXT '...'

When someone logs in they have a security context and what they can
access is then decided. You can't reconfigure what someone has access
to with anything within the DB (other than label changes), the SE-PgSQL
rules are elsewhere. That's what "Mandatory" refers to.

> but I'm not sure what application do you suppose. For example,
> if we protect web application from SQL injection attacks, the
> password column for each row can be read only from the end user
> represented by the row. The number of security labels will be same
> as the number of end users (= rows).

This example is also strange: the program that needs to read the
password need to be able to see all rows because by definition the user
cannot be logged in yet. After you login there is no need to be able to
read your own password. So column-access control is fine here.

And even if there are lots of contexts, so what? Security is not free,
but given SE-PgSQL is in use in the real world, clearly people think
the tradeoffs are worth it.

Finally, this is not about protection against SQL injection, it's protection
against people in Sales reading data belonging to Finance.

> ==== Actual benefits of SE-PgSQL ====
> SE-PgSQL will be committed step-by-step -- but could you explain which step
> can solve which problem in the real world? Imagine that SQL injections,
> measure for SOX Act, divulgation of personal information, .... They are
> security holes in terms of a whole application, but not a hole in terms of
> database, because database cannot always distinguish between legal and
> illegal data access (ex. correction of wrong data vs. rigging of benefits).

As far as I can tell, just about all the interesting cases are for
row-level security. While MAC on tables and columns will be
interesting, my guess the real uptake will be when row-level control is
in.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.