Report of PGcon2010

Report of PGcon2010

[KaiGai Kohei]

At May 19-21, PostgreSQL community held an annual conference called
PGcon2010 at Ottawa, Canada.
  http://www.pgcon.org/2010/

I also attended the conference and developer meeting (invitation only)
to have a talk about development of SE-PostgreSQL. So, I'd like to
report what we discussed here for SELinux community also.

Background
-----------
Last two years, I've joined to the development cycle of PostgreSQL to
integrate features to support SELinux. But it had not been progressed
due to some reasons; patch size is too large to commit at once, no
person (except for me) familiar with both of SELinux and PostgreSQL,
and so on.

At last winter, Stephen Frost suggested me to refactor existing PG's
security checks look like LSM/XACE, prior to SELinux code.
In another day, they invited Joshua Brindle and David P.Quigley to
BWPUG (Baltimore/Washington PostgreSQL Users Group) meeting to talk
with SELinux folks, although I didn't here.
  http://wiki.postgresql.org/wiki/SEPostgreSQL_Review_at_the_BWPUG
It seems to me they consented the design like LSM/XACE works well.
Then, I also agreed to develop it with this approach in the next
development cycle.

Discussion in PGcon2010
-----------------------
All major contributors were here, such as developer summit.

I introduced my idea at the developer meeting.

It tries to refactor the existing PG security check routines into
an separate function (E.g, check_relation_create(...)) which also
performs as an entry point of an external security provider.

In addition, it also tries PostgreSQL to support a feature to assign
a certain text label on database objects. It shall be available for
all the label based MAC, not only SELinux.

As long as PostgreSQL provides security hooks and security labeling,
it is not necessary SE-PostgreSQL feature is statically linked.
So, I also proposed it is an option that SELinux specific logic shall
be installed using a loadable module. It enables to reduce the burden
to review unfamiliar code from PostgreSQL community, and it also
means SELinux community (mainly, I and NEC, of course) takes on the
duty of maintenance of the module.

I was suggested that refactoring of the existing PG security checks
should be separated into more-and-more small unit to make its change
set more obvious, and we should start up with minimum functionalities.
I agreed with the approach. We decided to add a security hook to
acquire control on DML permission checks at first, because DML checks
are the hottest code in PgSQL rather than any other DDLs.

In addition, we agreed it is necessary to support security labeling
features for various kind of label based MAC features. Apart from
the security hooks, it shall be developed.

Development plan
-----------------
Now I'm tackling to add the first security hook at the routine which
applies the existing PG permissions checks on DML statements.
If and when it will be available, the upcoming SE-PgSQL module will
be able to provide a minimum demonstration.

In parallel, I'm also working to develop the SE-PgSQL module being
suitable for the security hooks in the upstream PostgreSQL.

The architecture of SE-PgSQL feature was significantly changed,
but I believe we are on the best way. It will make happy not only
SELinux users, but Smack or others also.

Stephen Frost also noticed me yesterday that BWPUG plans to have
a meeting about "SE-PostgreSQL Status and Review" at the Augast,
so they want to invite some of SELinux folks.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Report of PGcon2010

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

Greg, all,

* Greg Smith (greg@2ndquadrant.com) wrote:
> This pushes off the problem of how to keep labels consistent in the face
> of things like table changes to being a database superuser only task,
> not one you can delegate to other users.

As an additional side-note that might be relevant to this community,
I've been talking to some of the other PG developers (Tom Lane, Robert
Haas, etc) about adding more granularity to the PG role options to
eliminate the need to have an actual PG "super-user".  There are still
some specific tasks which require super-user (in particular, the
"replication" user must be a super-user, the user which can issue
pg_start_backup/pg_stop_backup commands, etc), but if we make those into
separately tracked options, we could provide a system with no user
having the actual "super-user" bit set which would still be very usable.

I'm hoping to target that for 9.1, but I certainly can't make any
promises.  One thing to note in all of this, as has likely been said
here already, right now this is just about all spare-time work by the PG
individuals and companies who are interested in it.  Organizations
interested in this speaking up that they'd like to use it, or even
better sponsor work on it, in whatever way they can, would certainly
increase the availability of PG community resources for this project and
things like RLS being added to PG.

	Thanks!

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Report of PGcon2010

[Xavier Toth]

On Fri, Jun 11, 2010 at 10:41 AM, Stephen Frost <sfrost@snowman.net> wrote:
> Greg, all,
>
> * Greg Smith (greg@2ndquadrant.com) wrote:
>> This pushes off the problem of how to keep labels consistent in the face
>> of things like table changes to being a database superuser only task,
>> not one you can delegate to other users.
>
> As an additional side-note that might be relevant to this community,
> I've been talking to some of the other PG developers (Tom Lane, Robert
> Haas, etc) about adding more granularity to the PG role options to
> eliminate the need to have an actual PG "super-user".  There are still
> some specific tasks which require super-user (in particular, the
> "replication" user must be a super-user, the user which can issue
> pg_start_backup/pg_stop_backup commands, etc), but if we make those into
> separately tracked options, we could provide a system with no user
> having the actual "super-user" bit set which would still be very usable.
>
> I'm hoping to target that for 9.1, but I certainly can't make any
> promises.  One thing to note in all of this, as has likely been said
> here already, right now this is just about all spare-time work by the PG
> individuals and companies who are interested in it.  Organizations
> interested in this speaking up that they'd like to use it, or even
> better sponsor work on it, in whatever way they can, would certainly
> increase the availability of PG community resources for this project and
> things like RLS being added to PG.
>
>        Thanks!
>
>                Stephen
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkwSWR0ACgkQrzgMPqB3kigJ7wCfcPofOMQYgr+9AGf+AskPZWWz
> ipUAnRcZqQ8NZjYLvpmrFbSDN9FHqQOC
> =C/J2
> -----END PGP SIGNATURE-----
>
>

Is there any hope for some sort of Common Criteria
testing/certification of SELinux PostgreSQL?

Ted


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Report of PGcon2010

[Stephen Frost]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

* Xavier Toth (txtoth@gmail.com) wrote:
> Is there any hope for some sort of Common Criteria
> testing/certification of SELinux PostgreSQL?

I think it would need someone to sponsor it/the work involved..  I'm not
sure what changes, if any, would be needed to the system to support
that.  I definitely think it'd be great if it happened.

	Thanks,

		Stephen

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Report of PGcon2010

[KaiGai Kohei]

(2010/06/12 1:12), Stephen Frost wrote:
> * Xavier Toth (txtoth@gmail.com) wrote:
>> Is there any hope for some sort of Common Criteria
>> testing/certification of SELinux PostgreSQL?
> 
> I think it would need someone to sponsor it/the work involved..  I'm not
> sure what changes, if any, would be needed to the system to support
> that.  I definitely think it'd be great if it happened.
> 

>From perspective of the functionalities, eventually, it shall provide
label based data flow control features, such as Oracle Label Security,
but the development cycle is going to be incremental.
So, it is impossible to release complete features at once.

>From perspective of the sponsorship, it shall become a next theme to
the development of functionalities. Of course, I have an intention to
encourage our company to fund the certification.
However, it is the least prerequisite that SELinux module will perform
on the upstreamed PostgreSQL.

Hence, it is a long term theme for us, but it will be hopeful.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Report of PGcon2010

[KaiGai Kohei]

It seems to me Greg's message was not distributed via SELinux list.

I'd like to send it again.

-------- Original Message --------
Subject: Re: Report of PGcon2010
Date: Fri, 11 Jun 2010 11:21:58 -0400
From: Greg Smith <greg@2ndquadrant.com>
To: KaiGai Kohei <kaigai@ak.jp.nec.com>
CC: SELinux <selinux@tycho.nsa.gov>,    Stephen Frost <sfrost@snowman.net>,    Robert Haas <robertmhaas@gmail.com>

KaiGai Kohei wrote:
> I was suggested that refactoring of the existing PG security checks
> should be separated into more-and-more small unit to make its change
> set more obvious, and we should start up with minimum functionalities.
> I agreed with the approach. We decided to add a security hook to
> acquire control on DML permission checks at first, because DML checks
> are the hottest code in PgSQL rather than any other DDLs.
>

I wanted to expand on this so it's clear what direction this is going
now and why it went there. I've been working on this project on the
PostgreSQL side mainly as an advocate for its inclusion, rather than as
someone coding on it.

Much of the trouble trying to integrate previous SE-PostgreSQL versions
related to relatively underused portions of SQL. For example, the most
problematic and contentious code path was when ALTER TABLE was used to
modify a table, a statement which due to its structure acquires
permissions in multiple spots. The way earlier patches were structured,
committing anything at all related to SE-PostgreSQL was blocked behind
resolving every one of these problem areas in every command. That was
more than the PostgreSQL community could really absorb in one commit.
And it wasn't clear what simpler subset would by itself by useful,
having already removed row-level security out of the initial target
feature set.

Now that we've been doing regular brainstorming about how to find a
subset of SE-PostgreSQL that could be committed for over six months,
during periodic meetings on that topic here in the US, Stephen Frost
(original author of the PostgreSQL "roles" system used for user
authentication in the database) made an interesting observation. If
instead you limit the focus to DML statements such as SELECT, INSERT,
and UPDATE, the permissions checks for these are for the most part all
sitting in one place in the PostgreSQL code: the query executor. It's
possible to connect a simplified version of SE-PostgreSQL that only aims
to restrict that type of statement, inserting a much simpler security
check hook only at that point, and end up with a dramatically smaller patch.

This pushes off the problem of how to keep labels consistent in the face
of things like table changes to being a database superuser only task,
not one you can delegate to other users. If the security hook code can
get committed even in that limited form, it accomplishes two things.
First, it finally introduces the possibility that core PostgreSQL will
ship with some SE-PostgreSQL code integrated in, which I think will
considerably expand interest in this specific area. Second, it lets
further improvements that add additional features do so one at a time
with relatively small code drops; maybe CREATE TABLE support is added
one month, ALTER TABLE the next.

My personal opinion is that systems setup by a superuser with
appropriate labeling that work for SELECT/INSERT/UPDATE are actually
sufficient to support some interesting use cases, and the incremental
improvement provided by DDL such as CREATE/DROP/ALTER can be postponed
and still have a useful result. I'd even rather see row-level results
(which have broader problems beyond just security framework integration
to be sorted out) tackled second here, after DML but before DDL. They
can certainly be worked on in parallel once basic DML is committed.

The next meeting of our local Baltimore/Washington PostgreSQL working
group that will focus on issues around SE-PostgreSQL is tentatively
scheduled for August 11th in Columbia, MD. We welcome input there from
other members of the security community who'd like to see SELinux
support integrated into PostgreSQL.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us

-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.