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

Tom Lane wrote:
> After that, and a whole bunch of foolery with manually putting the right
> security labels on files (because the contrib module is unhelpful for
> test installations with nonstandard PREFIXes), I managed to get a
> version that worked well enough to test. What I found out:

I'll improve the way to provide security policy.
Please wait for a while.

> * It does not come close to passing the regression tests. I saw a lot of
> ! ERROR: unrecognized node type: 903
> which suggests that something's been screwed up about parse analysis
> (903 = T_A_Const, which shouldn't get further than parse analysis),

Could you tell me what queries hit these errors?
I guess this message was generated in expression_tree_walker() called within
sepgsqlExprWalker(), but it is invoked after query rewriter.

> and it dumps core in the TRUNCATE test.

This bug came from misoperations of List.

> * pgbench shows a relatively marginal speed difference, which is not
> too surprising since it pushes only a few tuples around per query.
> The worst case for sepostgres is likely to be bulk operations.
> I tried "select count(*) from accounts" (at scale factor 20, so this
> is 2000000 tuples) and got about 550 msec from CVS HEAD, about
> 1340 msec from HEAD plus patch. That's with no actual useful policy
> loaded, mind you.
>
> So the overhead is indeed pretty bad, but it seems reasonable to think
> that with some optimization effort it could be brought down to where
> it'd be acceptable for people who really need the feature.

Thanks for your information.
It indeed has performance degrading, but, I expect users who want to apply
SELinux policy don't put their first priority on edge performance.

> AFAICS the only thing left that really needs to be discussed more during
> this commit-fest is the business about whether it's sane to be trying to
> apply selinux restrictions in simple_heap_update and friends. The more
> I think about that the more I think it's simply a bad idea. Those
> functions are used primarily (if not solely) for system-initiated
> catalog updates, and I fail to see any plausible reason to let
> user-written policy be applied at that level. For instance, it would
> be a completely bad move to allow such policy to prevent autovacuum
> from updating relfrozenxid values.

In generally, fewer and more fundamental security checks are more
comprehensive. simple_heap_update() can trap any updating, called
from more than 80 places.

The purpose of SE-PostgreSQL is to apply security policy on user's
queries, not an internal one. Therefore, we don't apply any policy
on some of *internal* operations, like updating TOAST table.

Currently I don't apply any special care for autovacuum, however,
it is a solution to handle *internal* updating as an exception for
checks. (Because it is NOT came from external users.)

> Furthermore, those functions are
> much too low-level to have any idea of the reason for the change they
> are being asked to make, so they can't apply any intelligence to the
> allow-or-not decision.

We can abstract finer-grained access control unit later, however,
its reverse is difficult.
For example, we have to have the following permission to create
a new table.
- Insert a new tuple into pg_class
- Insert a new tuple into pg_type
- Insert new tuples into pg_attribute

These are abstracted in the default security policy.
If you want non-administrative users to create/drop table,
set sepgsql_enable_users_ddl boolean to turn on/off the permission set.

# setsebool sepgsql_enable_users_ddl=1

> Lastly, I don't see any use-case for policy there
> that wouldn't be served as well or better by the standard SQL privilege
> mechanism. So I think that really all needs to be ripped out, and
> do enforcement in the executor instead.

The primary purpose of SE-PostgreSQL is to apply common access control
policy on database objects, as if clients access filesystem objects.

See the following diagram:
http://sepgsql.googlecode.com/files/sepgsql_dfc.png

It shows two users within different domain tries to communicate each
other, and any message have to go through inter-processes communication
method like files, networks, and so on.
(Security policy enforces single directed data flow, from lower to higher.)

SELinux can prevent data leaking via shared files because it is managed
by operating system. However, it is impossible for database objects.

SE-PostgreSQL apply (system-wide) common security policy on database objects.
This concept enables to maintain consistency of access control policy.

The standard SQL privilegs machanism is suitable to control accesses
on database objects, however, it is not easy to maintain its consistency
with operating systems's policy.

Is it appropriate answer for your question?

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>