Re: [RFC] PostgreSQL Access Control Extension (PGACE)

As I announced alpha version of SE-PostgreSQL about one month ago,
I'm working for development of a security facility integrated with
secure operating system.

It provides database users fine grained mandatory access control
including row and column level one, and integration with operating
system security policy.

This concept may have applicability to other secure operating system
such as Trusted Solaris. Just after the announcement, Sun.com's people
were interested in SE-PostgreSQL works, and contacted me.
They also want to implement a similar functionality on their operating
system using Trusted Extension (TX).

We got an agreement that a common framework like LSM will be useful
to implement and maintain those secure facilities.

I want to have a discussion and get feedbacks about this idea from
PostgreSQL developers.

----------
The framework named PGACE(PostgreSQL Access Control Extension).
It provides two major facilities. One is hooks on some strategic points.
The other is a functionality to associate a tuple with its security
attribute.

Any hooks is defined as a static inline functions in "security/pgace.h".
They give no effect, if no security facilities are configured.
If SELinux support is enabled via configure script, those definitions
are overwritten by "security/sepgsql.h", and the hooks calls actual
SE-PostgreSQL implementation to provide MAC(mandatory access control).

Those hooks are deployed on the some strategic points of PostgreSQL such as
simple_heap_insert(), PortalStart() and so on.

You can get all the definition of pgace.h and sepgsql.h from the following URL:
http://sepgsql.googlecode.com/svn/trunk/src/include/security/

The later functionality enables to associate a tuple with security attribute.
It adds a new field (t_security) with Oid type into HeapTupleHeaderData
structure. The t_security can persistently hold a Oid of pg_security new
system catalog. The pg_security has a combination of Oid value and security
attribute with text representation.

Database users can refer the attribute via new system column.
When SQL query tries to refer this attribute via the system column,
PGACE lookups pg_security system column to get a tuple which has same oid
compared to t_security value of its HeapTupleHeaderData.
It's implemented as input/output handler of new security_label type.

The name of system column is defined in pg_config.h.in.
In SELinux case, it's named "security_context". This system column is
writable via UPDATE or INSERT statement, to enables relabeling.

Because most of security attribute shares same text representation, this
implementation works effectively and economically.

As you know, PostgreSQL handles any database object as a tuple stored in
system catalogs. So, this concept may have applicability to any kind of
database object like table, column and procedure.
----------

I hope that SE-PostgreSQL and PGACE are merged into future upstreamed
PostgreSQL and we can turn on/off by configure option without any patch.

I believe any comments and feedbacks are so helpful to indicate the
direction of our development with an approach which is acceptable by
PostgreSQL development community.

Thanks,

* Reference
The full set of patch is a bit large to post the list directly. (6.7KL)

You can checkout the source code from the following URL:
http://code.google.com/p/sepgsql/source
You can get the patch for SE-PostgreSQL based on PGACE from the following URL:
http://sepgsql.googlecode.com/files/sepostgresql-8.2.3-226.patch
(against to the stable postgresql-8.2.3)
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Josh Berkus wrote:
> KaiGai,
>
>> It provides database users fine grained mandatory access control
>> including row and column level one, and integration with operating
>> system security policy.
>
> Column level? We don't currently support that, except through VIEWs.
> How is it implemented?
>

What's more, we have a SoC project for column level access controls.

cheers

andrew

KaiGai,

> It provides database users fine grained mandatory access control
> including row and column level one, and integration with operating
> system security policy.

Column level? We don't currently support that, except through VIEWs.
How is it implemented?

--Josh

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Column level? We don't currently support that, except through VIEWs.
> How is it implemented?

It wasn't clear to me how much of this is actually working today and how
much is a paper design --- one thing in particular that stood out as
probable handwaving was the bit about being able to assign to a system
column in INSERT or UPDATE. I'm fairly sure that that would take some
*significant* redesign of querytree and plan targetlist representation
:-( ... I looked at it once for OIDs and decided it wasn't worth the
trouble.

regards, tom lane

"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
> What's more, we have a SoC project for column level access controls.

... which presumably wouldn't involve any added dependency on outside code.
For people who are already using SELinux or Trusted Solaris, making the
database dependent on that infrastructure might be seen as a plus, but
I'm not sure the rest of the world would be pleased. There are also
some interesting questions about SQL spec compliance and whether a
database that silently hides some rows from you will give semantically
consistent results.

regards, tom lane

Tom Lane wrote:
> "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>
>> What's more, we have a SoC project for column level access controls.
>>
>
> ... which presumably wouldn't involve any added dependency on outside code.
>

Quite so. You can see the project description at
http://code.google.com/soc/postgres/appinfo.html?csaid=E272DA8E6521568F

> For people who are already using SELinux or Trusted Solaris, making the
> database dependent on that infrastructure might be seen as a plus, but
> I'm not sure the rest of the world would be pleased.

Even where SELinux is available it has had mixed reviews - I habitually
disable it.

cheers

andrew

Josh Berkus wrote:
> KaiGai,
>
>> It provides database users fine grained mandatory access control
>> including row and column level one, and integration with operating
>> system security policy.
>
> Column level? We don't currently support that, except through VIEWs.
> How is it implemented?

PGACE provides a hook just after query rewriting phase.
SE-PostgreSQL walks on the query tree to check any required references
onto columns, as the implementation of the hook.
If a client does not have enough permissions onto the column,
SE-PostgreSQL abort the current transaction via ereport().

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> Column level? We don't currently support that, except through VIEWs.
>> How is it implemented?
>
> It wasn't clear to me how much of this is actually working today and how
> much is a paper design --- one thing in particular that stood out as
> probable handwaving was the bit about being able to assign to a system
> column in INSERT or UPDATE. I'm fairly sure that that would take some
> *significant* redesign of querytree and plan targetlist representation
> :-( ... I looked at it once for OIDs and decided it wasn't worth the
> trouble.

Currently, writable system column support is already included as a part
of PGACE, and it works fine to make setting up SE-PostgreSQL.
The implementation uses TargetEntry->resjunk effectively to make it simplified.

When a targetlist contains "security_context" column in a UPDATE or INSERT
query, SE-PostgreSQL marks the TargetEntry as a junk.
Then, the value explicitly given as "security_context" is computed in the
normal way. It is fetched at ExecutePlan() just before calling ExecUpdate()
or ExecInsert(), and stored into HeapTupleHeader->t_security.

Maybe, a part of the patch to implement them is less than 100L, without any
significant redesign,
Is there any oversight? If so, please tell me.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Tom Lane wrote:
> "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>> What's more, we have a SoC project for column level access controls.
>
> ... which presumably wouldn't involve any added dependency on outside code.
> For people who are already using SELinux or Trusted Solaris, making the
> database dependent on that infrastructure might be seen as a plus, but
> I'm not sure the rest of the world would be pleased.

The most significant purpose of PGACE and SE-PostgreSQL is integration
between database and operating system security policy, on mandatory
access controlled (MAC) system especially.
Thus, not to provide any regression is the most desired behavior of
PGACE on non-MAC system like SELinux disabled Linux, I think.

PGACE without using SELinux or Trusted Solaris does not give any effect,
because it is defined as static inline function with no operation mostly.

> There are also
> some interesting questions about SQL spec compliance and whether a
> database that silently hides some rows from you will give semantically
> consistent results.

Any violated tuples are always filtered from result set, before using them,
as if an additional condition is appended onto WHERE or JOIN ON clause.
The condition means whether client has enough permission on this tuple, or not.
All those processes are done after rewriting phase, so result set is constant
even if a table is referred via views.

Thus, client can deal a table as if it does not contain any violated tuples.
# If a result set contains any violated tuple, it's a bug of SE-PostgreSQL.

An exception is foreign key implementation. It internally uses UPDATE query
to support 'ON UPDATE CASCADE' rule and so on.
If violated tuples are filtered, the FK constraint is not kept.
For example, when there are five tuples to be cascaded but client does not
have enough permission onto two of them, the two tuple will be remained
without cascading.
In SE-PostgreSQL, whole of transaction will be aborted, if client does not
have enough permissions on all the tuples cascaded under FK processing.

One more exception is TRUNCATE statement. In SE-PostgreSQL, TRUNCATE statement
is nonsense, because it is translated into unconditional DELETE statement to
avoid removing tuples without enough permission.

Currently, I have not gotten any inconsistency in the access control model.
But any pointed out is welcome.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

>> For people who are already using SELinux or Trusted Solaris, making the
>> database dependent on that infrastructure might be seen as a plus, but
>> I'm not sure the rest of the world would be pleased.
>
> Even where SELinux is available it has had mixed reviews - I habitually
> disable it.

The relationship between your works and SE-PostgreSQL effort is similar
to the relationship between UNIX-DAC/Posix-ACL and SELinux on operating
systems.

I believe those are not conflicted efforts.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Tom, Andrew, KaiGai,

> "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>> What's more, we have a SoC project for column level access controls.

I don't see the SE stuff as a replacement for that, since it apparently
exists outside the standard SQL security model.

> ... which presumably wouldn't involve any added dependency on outside code.
> For people who are already using SELinux or Trusted Solaris, making the
> database dependent on that infrastructure might be seen as a plus, but
> I'm not sure the rest of the world would be pleased.

Yes, I was thinking that this should be a compile-time option with a lot
of warnings in the Docs.

Give the team some credit, though; they've managed to come up with a
system that integrates OS-level ACLs for both SElinux and TxSol, are not
asking us to incorporate two different sets, and are coming to us with a
serious proposal that has a lot of work behind it. Please don't blow
them off like they were undergrads submitting a semester project. If
they need to come back after 8.3 beta so we can properly pay attention
to the proposal, then say so.

There are also
> some interesting questions about SQL spec compliance and whether a
> database that silently hides some rows from you will give semantically
> consistent results.

Yeah -- that's a potentially serious issue; KaiGai, have you looked into it?

--Josh Berkus

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Give the team some credit, though; they've managed to come up with a
> system that integrates OS-level ACLs for both SElinux and TxSol, are not
> asking us to incorporate two different sets, and are coming to us with a
> serious proposal that has a lot of work behind it. Please don't blow
> them off like they were undergrads submitting a semester project. If
> they need to come back after 8.3 beta so we can properly pay attention
> to the proposal, then say so.

Well, personally I won't have any cycles to think hard about any post-8.3
work until after the beta is out.

regards, tom lane

>> ... which presumably wouldn't involve any added dependency on outside
>> code.
>> For people who are already using SELinux or Trusted Solaris, making the
>> database dependent on that infrastructure might be seen as a plus, but
>> I'm not sure the rest of the world would be pleased.
>
> Yes, I was thinking that this should be a compile-time option with a lot
> of warnings in the Docs.

Yes, those facilities are not enabled without '--enable-selinux' compile-time
option. It's a bit unclear for me what means the "a lot of warnings the Docs".

> Give the team some credit, though; they've managed to come up with a
> system that integrates OS-level ACLs for both SElinux and TxSol, are not
> asking us to incorporate two different sets, and are coming to us with a
> serious proposal that has a lot of work behind it. Please don't blow
> them off like they were undergrads submitting a semester project. If
> they need to come back after 8.3 beta so we can properly pay attention
> to the proposal, then say so.

I don't hurry to merge those facilities regardless.
(8.3 is already feature frozen, as announced earlier.)

As I mentioned at first, the purpose of this discussion is to obtain
any feedbacks from PostgreSQL community, for our development.
I believe it also helps SE- stuff to be merged in the later version
of PostgreSQL.

> There are also
>> some interesting questions about SQL spec compliance and whether a
>> database that silently hides some rows from you will give semantically
>> consistent results.
>
> Yeah -- that's a potentially serious issue; KaiGai, have you looked into
> it?

Yes, I consider the policy to filter any violated tuple looks consistently.
The policy enforces any tuple has to be filtered before using them, and
it helps that computational processes don't get any effect from them.

But proving innocence is generally hard task.
At first, I want to know what points are you worried about the most.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> writes:
>>> There are also
>>> some interesting questions about SQL spec compliance and whether a
>>> database that silently hides some rows from you will give semantically
>>> consistent results.
>>
>> Yeah -- that's a potentially serious issue; KaiGai, have you looked into
>> it?

> Yes, I consider the policy to filter any violated tuple looks consistently.
> The policy enforces any tuple has to be filtered before using them, and
> it helps that computational processes don't get any effect from them.

> But proving innocence is generally hard task.
> At first, I want to know what points are you worried about the most.

Unique constraints and foreign-key constraints seem the most pressing
problems. What will you do to avoid having different viewers have
different opinions about whether a constraint is violated?

regards, tom lane

Tom Lane wrote:
> KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> writes:
>>>> There are also
>>>> some interesting questions about SQL spec compliance and whether a
>>>> database that silently hides some rows from you will give semantically
>>>> consistent results.
>>> Yeah -- that's a potentially serious issue; KaiGai, have you looked into
>>> it?
>
>> Yes, I consider the policy to filter any violated tuple looks consistently.
>> The policy enforces any tuple has to be filtered before using them, and
>> it helps that computational processes don't get any effect from them.
>
>> But proving innocence is generally hard task.
>> At first, I want to know what points are you worried about the most.
>
> Unique constraints and foreign-key constraints seem the most pressing
> problems. What will you do to avoid having different viewers have
> different opinions about whether a constraint is violated?

The behavior of unique constraints are kept as is. Thus, a client with
some hidden tuples may not be able to insert a new tuple, though the tuple
seems to him containing unique values.
>From strict security viewpoint, this behavior has a possibility to leak the
existence of hidden tuples to clients without enough permissions.
To resolve them, polyinstantiation table support will be required ultimately.

When a client tries to insert a new tuple into a table in which foreign-key
constraints are configured, the foreign-key values have to be included in his
scope. If not so, the current transaction will be aborted.
If the constraint has CASCADE rule, all the foreign-keys have to be updated
when the value of primary key is changed. It is an exception for the policy
to filter. If the client have any violated tuple, whole the process will be
aborted. In normal cases, those tuples are merely excluded from the target of
updating, although.

As the conclusion, we intend to keep the consistency of any constrains.
But some issues are remained from strict security viewpoint.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>