Re: Updates of SE-PostgreSQL 8.4devel patches (r1168)

KaiGai Kohei wrote:
> > I just looked over the patch. This new version with row-level SQL
> > security has certainly reduced the SE-Linux-specific part, which is
> > good.
> >
> > It was interesting how you implemented SQL-level column-level
> > permissions:
> >
> > CREATE TABLE customer (
> > cid integer primary key,
> > cname varchar(32),
> > credit varchar(32) SECURITY_CONTEXT = 'system_u:object_r:sepgsql_secret_table_t'
> > );
> >
> > I am unclear how that will behave with the column-level permissions
> > patch someone is working on. I am wondering if your approach is clearer
> > than the other patch because it gives a consistent right policy for rows
> > and columns.
>
> The column-level permissions in SE-PostgreSQL works independently and
> orthogonally from the upcoming column-level permissions by Stephen Frost.
> When the SE-PostgreSQL is enabled, both of facilities have to allow the
> client to access required columns.
>
> In the above case, the "credit" column has "sepgsql_secret_table_t" type,
> but rest of columns inherits the type of "customer" table which allows
> non-administrative users to access in the default security policy.
> If the given query contains the "credit" column, SE-PostgreSQL checks
> privileges of client to access columns labeled as "sepgsql_secret_table_t",
> then it raises an error to abort the current transaction if the security
> policy does not allow it.
>
> There is a possibility that column-level ACLs are set via newer GRANT/REVOKE
> statement. In this case, the core PostgreSQL checks them, and raises an error
> if violated.

OK. I am wondering if we _want_ two ways to set column permisions,
especially since I think there will be only one way to set row-level
permissions.

> > I was wondering why you mention the NSA (U.S. National Security Agency)
> > in the patch?
> >
> > +# NSA SELinux support
>
> The original author of SELinux is NSA.
> There is no more meanings than a caption of the option.
> I'll fix it, if necessary.

Yes, please remove; the "NSA" suggests to me that this is an NSA-only
feature, which it is not; it was just originally designed for them.

> > The size of the patch is still larger but I don't see any way to reduce it:
> >
> > 1275 sepostgresql-docs-8.4devel-3-r1168.patch
> > 625 sepostgresql-pg_dump-8.4devel-3-r1168.patch
> > 829 sepostgresql-policy-8.4devel-3-r1168.patch
> > 1736 sepostgresql-row_acl-8.4devel-3-r1168.patch
> > 10847 sepostgresql-sepgsql-8.4devel-3-r1168.patch
> > 1567 sepostgresql-tests-8.4devel-3-r1168.patch
> > 16879 total
>
> I thought the "sepostgresql-docs" can be replaced by the pointing to the wiki
> page, how do you think the idea?

No, I docs for using the tarball should be in the main documentation,
even if they are not compile-enabled by default. The new patch affects
the main Postgres backend code much less, which is a great improvement.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +