Re: [0/4] Proposal of SE-PostgreSQL patches

Andrew Sullivan <ajs(at)commandprompt(dot)com> writes:
> There is an issue in most high-security systems having to do with
> side-channel leakage of supposedly sensitive data. So, the mere
> exsistence of certain tables, columns, or users might be regarded as
> security-sensitive data. I'm not sure I see how to get around that
> without mucking in the areas that are causing some of the trouble.

Well, the setup that I suggested would still allow people to set
restrictions that would prevent *user* queries from seeing rows in the
system catalogs. I'm not sure that's a good idea either --- pg_dump,
meet foot gun --- but at least it can't corrupt the functioning of the
server itself.

> But I think before we get into that discussion, a fairly clear
> statement of exactly which problems are going to be in scope is
> needed.

Agreed, that would help.

> FWIW, I support and think important the row- and column- level access
> controls this seems to be proposing, at least in principle. Whether
> that's a support that will extend to 2x overhead on everything is
> rather a different matter. Also, I am more than prepared to trade
> away some cases in order to get a broadly useful functionality (so if
> you can't hide the existence of a table, but all efforts to learn its
> contents don't work, I might be willing to support that trade-off).

Yeah, that's something that we need to think about too. ISTM that this
patch's proposed restrictions on SQL object access are largely
duplicative of SQL-standard access permissions, and they'll become more
so if the pending patch to implement SQL column permissions gets in.
I think a good case could be made for throwing out all of that and using
the SELinux code only for row-level filtering.

(And of course the next question after that is why we should want to
depend on SELinux at all, rather than implementing row filtering
in the framework of SQL permissions...)

regards, tom lane