Re: SE-PostgreSQL Specifications

Here is the initial draft of SE-PostgreSQL specifications:

http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

I've described it from the scratch again with paying attention
for the people knowing nothing about SELinux.
In some points, it uses comparison between the database privilege
mechanism and SE-PostgreSQL for easy understanding.

Please point out, if ...
- Its composition can be improved.
- Here is not enough introductions for what user wants to know.
- Here is too much explanations, more brief one will be available.
- Here is not easy understandable for database folks.
- Here is not enough English quality.
- And so on...

In addition, I would like to fix its specifications during the discussion.

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

Excellent ... I'll try to have something tomorrow (Friday PDT) but I've got some non-work related issues which may keep from giving this a good look until the weekend (FWIW). I'll post any questions I have.

Thanks,

Greg W.

----- Original Message ----
From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org; KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>; Greg Williamson <gwilliamson39(at)yahoo(dot)com>; Sam Mason <sam(at)samason(dot)me(dot)uk>; Joshua Brindle <method(at)manicmethod(dot)com>
Sent: Thursday, July 23, 2009 9:54:10 PM
Subject: SE-PostgreSQL Specifications

Here is the initial draft of SE-PostgreSQL specifications:

http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

I've described it from the scratch again with paying attention
for the people knowing nothing about SELinux.
In some points, it uses comparison between the database privilege
mechanism and SE-PostgreSQL for easy understanding.

Please point out, if ...
- Its composition can be improved.
- Here is not enough introductions for what user wants to know.
- Here is too much explanations, more brief one will be available.
- Here is not easy understandable for database folks.
- Here is not enough English quality.
- And so on...

In addition, I would like to fix its specifications during the discussion.

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

On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
> Here is the initial draft of SE-PostgreSQL specifications:
>
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

Hey, this is really cool. Think it is a nice introduction. Fixed some
of the really obvious language stuff and an example but the English is
quite good.

One thing I know people are going to ask: why did you use names like
"create" and "delete" and not the usual names that postgresql itself
uses. I suspect the answer is because that's the standard naming used
in SELinux, but I think you need to spell that out somewhere.

The same for the db_* convention. Do you have a reference to naming
conventions for SELinux permissions?

I need to think it over some more, but it's a really good start.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.

Martijn van Oosterhout wrote:
> On Fri, Jul 24, 2009 at 01:07:54AM -0700, Greg Williamson wrote:
>> Here is the initial draft of SE-PostgreSQL specifications:
>>
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
>
> Hey, this is really cool. Think it is a nice introduction. Fixed some
> of the really obvious language stuff and an example but the English is
> quite good.

Thanks, but I found an incorrect change at the trusted procedure section.

Old)
CREATE TABLE customer (
cid integer primary key,
cname varchar(32),
credit varchar(32)
- SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'
- );

New)
CREATE TABLE customer (
cid integer primary key,
cname varchar(32),
credit varchar(32)
+ ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0';

This example intends to assign "secret" label on the credit column,
not whole of the table. Note that the default security context shall
be assigned on the table and rest of columns in this case.

| For example, when the customer table is defined as follows,
| unprivileged users cannot see the contents of customer.credit
| because it is labeled as sepgsql_secret_table_t which means
| all the accesses are denied from confined domains.

Is the description inadequate to note the example tries to assign
a certain security context on the customer.credit column?

BTW, in the later case, the table is labeled as "secret", then columns
inherit table's security context in the default, so the table and all
the columns are labeled as "secret".

> One thing I know people are going to ask: why did you use names like
> "create" and "delete" and not the usual names that postgresql itself
> uses. I suspect the answer is because that's the standard naming used
> in SELinux, but I think you need to spell that out somewhere.
>
> The same for the db_* convention. Do you have a reference to naming
> conventions for SELinux permissions?

http://oss.tresys.com/repos/refpolicy/trunk/policy/flask/access_vectors

All the object classes managed in userspace object manager have its prefix.
For example, X-window objects has x_* prefix.
Kenel objects don't have any prefix, such as "file".

Referring the other base object classes, it uses "create", "getattr",
"setattr", "relabelfrom" and "relabelto" commonly. However, a permission
to remove the object itself is named reflecting to the characteristics of
the object.
For example, file:{unlink} and ipc:{destroy} mean a permission to remove
itself. I believe "drop" is an appropriate naming for database objects.

TODO: add description at the "Object classes and permissions" why object
classes are prefixed by db_*

> I need to think it over some more, but it's a really good start.
>
> Have a nice day,

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

KaiGai,

* KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
> Here is the initial draft of SE-PostgreSQL specifications:
>
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

Thanks for this, it really does help, I believe. I've been reviewing it
and am also planning on helping refine and improve upon it. I'd like to
spend time working on the patch as well but I'm hesitant to commit to
that right now due to other obligations. We'll see how it goes.

Thanks again,

Stephen

On Fri, Jul 24, 2009 at 6:35 PM, Stephen Frost<sfrost(at)snowman(dot)net> wrote:
> Thanks for this, it really does help, I believe.  I've been reviewing it
> and am also planning on helping refine and improve upon it.  I'd like to
> spend time working on the patch as well but I'm hesitant to commit to
> that right now due to other obligations.  We'll see how it goes.

At this point, I think refining and improving the spec is probably
considerably more important than writing the code.

...Robert

On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
> Thanks, but I found an incorrect change at the trusted procedure section.
>
> Old)
> CREATE TABLE customer (
> cid integer primary key,
> cname varchar(32),
> credit varchar(32)
> - SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'
> - );
>
> New)
> CREATE TABLE customer (
> cid integer primary key,
> cname varchar(32),
> credit varchar(32)
> + ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0';
>
> This example intends to assign "secret" label on the credit column,
> not whole of the table. Note that the default security context shall
> be assigned on the table and rest of columns in this case.

The show_credit() function in this section would seem to leak authority
as well; it seems possible to determine if customers exist that
otherwise may otherwise hidden. For example, imagine we have a row
in the customer table with cid=1 whose security label would normally
prevent. We can perform:

SELECT show_credit(1);

and, as far as I can tell, this call would succeed.

--
Sam http://samason.me.uk/

Sam Mason wrote:
> On Sat, Jul 25, 2009 at 07:23:22AM +0900, KaiGai Kohei wrote:
>> Thanks, but I found an incorrect change at the trusted procedure section.
>>
>> Old)
>> CREATE TABLE customer (
>> cid integer primary key,
>> cname varchar(32),
>> credit varchar(32)
>> - SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0'
>> - );
>>
>> New)
>> CREATE TABLE customer (
>> cid integer primary key,
>> cname varchar(32),
>> credit varchar(32)
>> + ) SECURITY_LABEL = 'system_u:object_r:sepgsql_secret_table_t:s0';
>>
>> This example intends to assign "secret" label on the credit column,
>> not whole of the table. Note that the default security context shall
>> be assigned on the table and rest of columns in this case.
>
> The show_credit() function in this section would seem to leak authority
> as well; it seems possible to determine if customers exist that
> otherwise may otherwise hidden. For example, imagine we have a row
> in the customer table with cid=1 whose security label would normally
> prevent. We can perform:
>
> SELECT show_credit(1);
>
> and, as far as I can tell, this call would succeed.

This example shows that confined client cannot read credit card number
without using trusted procedure, but trusted procedure returns masked one.
It does not intend to hide existence of entries within customer table.

See the third box in the section.

postgres=# SELECT cid, cname FROM customer;
cid | cname
-----+-------
10 | jack
13 | adam
14 | liza
(3 rows)

This query does not read from customer.credit, so it should be succeeded.

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

On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
> Sam Mason wrote:
> >The show_credit() function in this section would seem to leak authority
> >as well; it seems possible to determine if customers exist that
> >otherwise may otherwise hidden. For example, imagine we have a row
> >in the customer table with cid=1 whose security label would normally
> >prevent. We can perform:
> >
> > SELECT show_credit(1);
> >
> >and, as far as I can tell, this call would succeed.
>
> This example shows that confined client cannot read credit card number
> without using trusted procedure, but trusted procedure returns masked one.
> It does not intend to hide existence of entries within customer table.

This would seem to imply that all user defined trusted code has to
perform its own permission checks. How is MAC any different from DAC in
the presence of code such as:

CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD
LANGUAGE 'sql'
SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0'
AS 'SELECT * FROM customer';

(I hope I've modified the example correctly!)

--
Sam http://samason.me.uk/

Sam Mason wrote:
> On Sat, Jul 25, 2009 at 09:16:47AM +0900, KaiGai Kohei wrote:
>> Sam Mason wrote:
>>> The show_credit() function in this section would seem to leak authority
>>> as well; it seems possible to determine if customers exist that
>>> otherwise may otherwise hidden. For example, imagine we have a row
>>> in the customer table with cid=1 whose security label would normally
>>> prevent. We can perform:
>>>
>>> SELECT show_credit(1);
>>>
>>> and, as far as I can tell, this call would succeed.
>> This example shows that confined client cannot read credit card number
>> without using trusted procedure, but trusted procedure returns masked one.
>> It does not intend to hide existence of entries within customer table.
>
> This would seem to imply that all user defined trusted code has to
> perform its own permission checks. How is MAC any different from DAC in
> the presence of code such as:
>
> CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD
> LANGUAGE 'sql'
> SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0'
> AS 'SELECT * FROM customer';
>
> (I hope I've modified the example correctly!)

In this case, confined users cannot create a function labeled as
'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is
controlled by db_procedure:{create} permission.

Confined user can create a function with "user_sepgsql_proc_exec_t"
(which is the default one for confined users), but it is not a trusted procedure,
so the "SELECT * FROM customer" is executed with confined user's privileges as is,
then it will be failed due to the lack of permission on the customer.credit.

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

On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
> Sam Mason wrote:
> >This would seem to imply that all user defined trusted code has to
> >perform its own permission checks. How is MAC any different from DAC in
> >the presence of code such as:
> >
> >CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD
> > LANGUAGE 'sql'
> > SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0'
> > AS 'SELECT * FROM customer';
>
> In this case, confined users cannot create a function labeled as
> 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is
> controlled by db_procedure:{create} permission.

Yes, that seems reasonable. The fact that you're still talking about
"confined users" is slightly worrying and would seem to imply that
there is still a superuser/normal user divide--it's probably just a
terminology thing though.

One thing I know I don't understand is what the security labels actually
mean; I've had a couple of searches through your pages now and can't see
anything described nor pointers to external documentation.

> Confined user can create a function with "user_sepgsql_proc_exec_t"
> (which is the default one for confined users), but it is not a trusted
> procedure, so the "SELECT * FROM customer" is executed with confined
> user's privileges as is, then it will be failed due to the lack of
> permission on the customer.credit.

So an "unconfined user" (whatever that means??) is basically working
with DACs then?

--
Sam http://samason.me.uk/

Sam Mason wrote:
> On Sat, Jul 25, 2009 at 10:43:05AM +0900, KaiGai Kohei wrote:
>> Sam Mason wrote:
>>> This would seem to imply that all user defined trusted code has to
>>> perform its own permission checks. How is MAC any different from DAC in
>>> the presence of code such as:
>>>
>>> CREATE OR REPLACE FUNCTION show_customers () RETURNS SETOF RECORD
>>> LANGUAGE 'sql'
>>> SECURITY_LABEL = 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0'
>>> AS 'SELECT * FROM customer';
>> In this case, confined users cannot create a function labeled as
>> 'system_u:object_r:sepgsql_trusted_proc_exec_t:s0', because it is
>> controlled by db_procedure:{create} permission.
>
> Yes, that seems reasonable. The fact that you're still talking about
> "confined users" is slightly worrying and would seem to imply that
> there is still a superuser/normal user divide--it's probably just a
> terminology thing though.
>
> One thing I know I don't understand is what the security labels actually
> mean; I've had a couple of searches through your pages now and can't see
> anything described nor pointers to external documentation.

I assume the wikipage (SEPostgreSQL_Draft) is a draft for the PostgreSQL
official documentation. However, the list of security labels originates
from the default security policy in SELinux.
So, I think an external link will be preferable for the references.

TODO: I'll make the list of security labels we can assign on.

>> Confined user can create a function with "user_sepgsql_proc_exec_t"
>> (which is the default one for confined users), but it is not a trusted
>> procedure, so the "SELECT * FROM customer" is executed with confined
>> user's privileges as is, then it will be failed due to the lack of
>> permission on the customer.credit.
>
> So an "unconfined user" (whatever that means??) is basically working
> with DACs then?

Sorry for using the undefined terminology.

The default security policy provides several security contexts that we
can assign on user's shell process, such as user_t, staff_t and unconfined_t.
(Please note that the security context of processes means its privileges.)

SELinux checks privileges of processes without any exceptions.
However, the default security policy allows anything on unconfined_t label.
It means "unconfined" users are allowed anything according to the policy.
(BTW, we can unplug the "unconfined" label using modular policy stuff.)

On the other hand, rest of security context (user_t, staff_t or httpd_t for
web servers) are "confined", because the security policy does not allow
such widespread permissions.

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

Sam Mason <sam(at)samason(dot)me(dot)uk> writes:
> Yes, that seems reasonable. The fact that you're still talking about
> "confined users" is slightly worrying and would seem to imply that
> there is still a superuser/normal user divide--it's probably just a
> terminology thing though.

There had better still be superusers. Or do you want the correctness
of your backups to depend on whether your SELinux policy is correct?
The first time somebody loses critical data because SELinux suppressed
it from their pg_dump output, they're going to be on the warpath.

regards, tom lane

On Jul 25, 2009, at 11:06 AM, Tom Lane wrote:

> Sam Mason <sam(at)samason(dot)me(dot)uk> writes:
>> Yes, that seems reasonable. The fact that you're still talking about
>> "confined users" is slightly worrying and would seem to imply that
>> there is still a superuser/normal user divide--it's probably just a
>> terminology thing though.
>
> There had better still be superusers. Or do you want the correctness
> of your backups to depend on whether your SELinux policy is correct?
> The first time somebody loses critical data because SELinux suppressed
> it from their pg_dump output, they're going to be on the warpath.

This behavior is no different than when taking/using an SE-enabled
filesystem backup. And woe to the "admin" who doesn't test his
backups- caveat emptor.

Still, it would be nice if pg_dump warned or stopped if the backup it
created was completely useless (missing data dependencies), no?

Cheers,
M

On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote:
> Sorry for using the undefined terminology.

I think this is the largest missing part of the docs at the moment;
there is a whole new world of definitions that need to be understood
before the SE-PG stuff is understandable/usable by anyone and none of it
is explained in a way I can understand. External links are fine at the
moment (I think) but descriptions will need to exist.

For example you currently define a "security context" as "a formatted
short string"---how does that tell me why I would want one or what it
does! As an example, PG currently has the following to describe what a
"role" is:

http://www.postgresql.org/docs/current/static/database-roles.html

I'd expect a similar definition for each of the major terms in SE-PG;
at the moment these seem to be "security label", "security context",
"security policy" and others? What do others think?

Hope that helps explain my confusion! If you point me at some docs I'll
be happy to write/edit things to make them more relevant to PG.

--
Sam http://samason.me.uk/

On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote:
> There had better still be superusers. Or do you want the correctness
> of your backups to depend on whether your SELinux policy is correct?

I thought the whole point of MAC was that superusers don't exist any
more--at least not with the power they currently do. Organizations may
well not trust specific parts of their database to certain types of
backups, SE-PG should allow this to be controlled somewhat.

> The first time somebody loses critical data because SELinux suppressed
> it from their pg_dump output, they're going to be on the warpath.

That should be solved by different methods; as "A.M" said pg_dump can
complain if it doesn't see everything it expected to (which should
handle the naive user case) and backdoors can be put in the scheme
that will (by default?) initially allow a "backup" subject unfettered
read-only access to each object. I'm expecting that this access can be
revoked as needed from sensitive tables.

--
Sam http://samason.me.uk/

On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason<sam(at)samason(dot)me(dot)uk> wrote:
> On Sat, Jul 25, 2009 at 11:06:37AM -0400, Tom Lane wrote:
>> There had better still be superusers.  Or do you want the correctness
>> of your backups to depend on whether your SELinux policy is correct?
>
> I thought the whole point of MAC was that superusers don't exist any
> more--at least not with the power they currently do.

It's been billed that way, but it's not really accurate. A more
accurate statement would be that it's possible to create a system in
which there is no unconfined role.

> Organizations may
> well not trust specific parts of their database to certain types of
> backups, SE-PG should allow this to be controlled somewhat.

I imagine it would be possible to run pg_dump on a database where you
couldn't see all of the objects, and get a dump of just those, but
that's only tangentially related to whether such things as superusers
exist. If superusers DON'T exist, that would be making the opposite
statement, namely, that there isn't ANY WAY to get a backup that you
can be sure DOES contain all of the objects. And while I believe
SE-Linux/SE-PostgreSQL would allow you to configure such a system, you
might want to think carefully before you decide to do so, and the
system certainly shouldn't (and can't) force you to set it up that
way.

>> The first time somebody loses critical data because SELinux suppressed
>> it from their pg_dump output, they're going to be on the warpath.
>
> That should be solved by different methods; as "A.M" said pg_dump can
> complain if it doesn't see everything it expected to (which should
> handle the naive user case) and backdoors can be put in the scheme
> that will (by default?) initially allow a "backup" subject unfettered
> read-only access to each object.  I'm expecting that this access can be
> revoked as needed from sensitive tables.

If pg_dump can tell that there is information missing, the system
hasn't done a very good job of hiding its existence, which is surely
the whole point here. Even if SE-PostgreSQL isn't explicitly worried
about eliminating covert channels, it seems like a terrible idea to
design a database backup tool that operates by exploiting ones we
haven't chosen to eliminate.

...Robert

On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
> On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason<sam(at)samason(dot)me(dot)uk> wrote:
> > I thought the whole point of MAC was that superusers don't exist any
> > more--at least not with the power they currently do.
>
> It's been billed that way, but it's not really accurate. A more
> accurate statement would be that it's possible to create a system in
> which there is no unconfined role.

Yes, that sounds more precise!

I'm still unsure of terminology; what's a "unconfined role"? I guess
the layman's description is similar to a "superuser", but I'm sure
there's a more refined definition somewhere. Hum, I've just found
Fedora's guide, is the following considered a reasonable picture:

http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html

> > Organizations may
> > well not trust specific parts of their database to certain types of
> > backups, SE-PG should allow this to be controlled somewhat.
>
> I imagine it would be possible to run pg_dump on a database where you
> couldn't see all of the objects, and get a dump of just those, but
> that's only tangentially related to whether such things as superusers
> exist.

I'm not sure what point you're trying to make; in my understanding
superusers can see and do anything--hence they can make a backup.

> If superusers DON'T exist, that would be making the opposite
> statement, namely, that there isn't ANY WAY to get a backup that you
> can be sure DOES contain all of the objects.

The traditional approach would be to maintain multiple physically
separate databases; in this setup it's obvious that when you perform a
backup of one of these databases you're only seeing a subset of "all of
the objects". Isn't SE-PG just allowing you to do this within a single
PG database?

> And while I believe
> SE-Linux/SE-PostgreSQL would allow you to configure such a system, you
> might want to think carefully before you decide to do so, and the
> system certainly shouldn't (and can't) force you to set it up that
> way.

I agree that this would seem to make the resulting system easier to
manage, however I can also imagine scenarios where the converse would
be true. This is a fuzzy engineering decision of the sort that I don't
like making without a use case---and it would be nice to have several
here.

> > pg_dump can complain if it doesn't see everything it expected to
>
> If pg_dump can tell that there is information missing, the system
> hasn't done a very good job of hiding its existence, which is surely
> the whole point here.

Hum, good point--scratch that idea then!

--
Sam http://samason.me.uk/

Sam Mason wrote:
> On Sat, Jul 25, 2009 at 09:50:08PM +0900, KaiGai Kohei wrote:
>> Sorry for using the undefined terminology.
>
> I think this is the largest missing part of the docs at the moment;
> there is a whole new world of definitions that need to be understood
> before the SE-PG stuff is understandable/usable by anyone and none of it
> is explained in a way I can understand. External links are fine at the
> moment (I think) but descriptions will need to exist.
>
> For example you currently define a "security context" as "a formatted
> short string"---how does that tell me why I would want one or what it
> does! As an example, PG currently has the following to describe what a
> "role" is:
>
> http://www.postgresql.org/docs/current/static/database-roles.html

Indeed, the draft used the term of "security context" with minimum
introductions, but not enough friendliness for database folks.

The purpose of security context is an identifier of any subject and
object to describe them in the security policy. Because the security
policy is common for operating system, databases, x-window and others,
any managed database objects needs its security context.

Anyway, I need to introduce them in the security model section.

> I'd expect a similar definition for each of the major terms in SE-PG;
> at the moment these seem to be "security label", "security context",
> "security policy" and others? What do others think?

The "security label" is an identical one with "security context".
Due to the historical reason, I uses a term of "SECURITY_LABEL" for
interfaces, but it might be more easy understandable to use
"SECURITY_CONTEXT" instead.

For the security policy, I introduce it at the security model section:

| Access control is conceptually to decide a set of allowed (or denied)
| actions between a certain subject (such as a database client) and an
| object (such as a table), and to apply the decision on user's requests.
| At the database privilege system, ACL stored in database objects itself
| holds a list of allowed actions to certain database roles, and it is
| applied on the user's request.
| SELinux also holds massive sets of allowed actions between a certain
| subject and a certain object, we call them security policy.

Is it obscure?

In addition, I also think it needs to define some other terms explicitly.
For example, what the term of "labeled" means.

> Hope that helps explain my confusion! If you point me at some docs I'll
> be happy to write/edit things to make them more relevant to PG.

At this point, the SELinux user's guide in Fedora is the most comprehensive
documentation. It is described from the viewpoint of SELinux users, not
experts or developers.

http://docs.fedoraproject.org/selinux-user-guide/

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

On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Kohei<kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> | Access control is conceptually to decide a set of allowed (or denied)
> | actions between a certain subject (such as a database client) and an
> | object (such as a table), and to apply the decision on user's requests.
> | At the database privilege system, ACL stored in database objects itself
> | holds a list of allowed actions to certain database roles, and it is
> | applied on the user's request.
> | SELinux also holds massive sets of allowed actions between a certain
> | subject and a certain object, we call them security policy.
>
> Is it obscure?

It's obscure to me. :-)

I think you need to define security policy more precisely and give at
least one or two examples of security policy entries.

...Robert

Robert Haas wrote:
> On Sat, Jul 25, 2009 at 11:27 PM, KaiGai Kohei<kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> | Access control is conceptually to decide a set of allowed (or denied)
>> | actions between a certain subject (such as a database client) and an
>> | object (such as a table), and to apply the decision on user's requests.
>> | At the database privilege system, ACL stored in database objects itself
>> | holds a list of allowed actions to certain database roles, and it is
>> | applied on the user's request.
>> | SELinux also holds massive sets of allowed actions between a certain
>> | subject and a certain object, we call them security policy.
>>
>> Is it obscure?
>
> It's obscure to me. :-)
>
> I think you need to define security policy more precisely and give at
> least one or two examples of security policy entries.

OK, I'll try to define it more precisely and introduce a few examples
in the documents.

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

On Sat, Jul 25, 2009 at 7:49 PM, Sam Mason<sam(at)samason(dot)me(dot)uk> wrote:
> On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
>> On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason<sam(at)samason(dot)me(dot)uk> wrote:
>> > I thought the whole point of MAC was that superusers don't exist any
>> > more--at least not with the power they currently do.
>>
>> It's been billed that way, but it's not really accurate.  A more
>> accurate statement would be that it's possible to create a system in
>> which there is no unconfined role.
>
> Yes, that sounds more precise!
>
> I'm still unsure of terminology; what's a "unconfined role"?  I guess
> the layman's description is similar to a "superuser", but I'm sure
> there's a more refined definition somewhere.  Hum, I've just found
> Fedora's guide, is the following considered a reasonable picture:
>
>  http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html
>
>> > Organizations may
>> > well not trust specific parts of their database to certain types of
>> > backups, SE-PG should allow this to be controlled somewhat.
>>
>> I imagine it would be possible to run pg_dump on a database where you
>> couldn't see all of the objects, and get a dump of just those, but
>> that's only tangentially related to whether such things as superusers
>> exist.
>
> I'm not sure what point you're trying to make; in my understanding
> superusers can see and do anything--hence they can make a backup.
>
>> If superusers DON'T exist, that would be making the opposite
>> statement, namely, that there isn't ANY WAY to get a backup that you
>> can be sure DOES contain all of the objects.
>
> The traditional approach would be to maintain multiple physically
> separate databases; in this setup it's obvious that when you perform a
> backup of one of these databases you're only seeing a subset of "all of
> the objects".  Isn't SE-PG just allowing you to do this within a single
> PG database?

Partly. There's also a concept called "read down", which is
important. It allows you to have, say, secret and classified data in
the same database, and let the secret users see both types but the
classified users see only the classified stuff, not the secret stuff.

If you want to store intelligence data about the war in Iraq and
intelligence data about the war in Afghanistan, it might not be too
bad to store them in separate databases, though storing them in the
same database might also make things simpler for users who have access
to both sets of data. But if you have higher and lower
classifications of data it's pretty handy (AIUI) to be able to let the
higher-secrecy users read the lower-secrecy data - if you used
separate databases to simulate read-down, you'd have to replicate data
between them, and also have some manual mechanism for tracking which
level of secrecy applied to which to which data.

All of the foregoing is my very layman's understanding of this, so
take it with a grain of salt.

...Robert

Sam Mason wrote:
> On Sat, Jul 25, 2009 at 04:39:29PM -0400, Robert Haas wrote:
>> On Sat, Jul 25, 2009 at 4:27 PM, Sam Mason<sam(at)samason(dot)me(dot)uk> wrote:
>>> I thought the whole point of MAC was that superusers don't exist any
>>> more--at least not with the power they currently do.
>> It's been billed that way, but it's not really accurate. A more
>> accurate statement would be that it's possible to create a system in
>> which there is no unconfined role.
>
> Yes, that sounds more precise!

Yes, Rober's explanation is correct.

> I'm still unsure of terminology; what's a "unconfined role"? I guess
> the layman's description is similar to a "superuser", but I'm sure
> there's a more refined definition somewhere. Hum, I've just found
> Fedora's guide, is the following considered a reasonable picture:
>
> http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/chap-Security-Enhanced_Linux-Targeted_Policy.html

Please note that SELinux/SE-PgSQL checks all the requests from users
without any exceptions, even if he is a superusers.
It makes its access control decisions based on the security policy.

The default security policy (which is provided by SELinux's community)
allows anything on the unconfined ones. Thus, it is allowed anything
at the result.
(Needless to say, DAC permission checks are applied independent from
whether it is confined or unconfined in SELinux.)

It is important the decision is always according to the security policy.

>> And while I believe
>> SE-Linux/SE-PostgreSQL would allow you to configure such a system, you
>> might want to think carefully before you decide to do so, and the
>> system certainly shouldn't (and can't) force you to set it up that
>> way.
>
> I agree that this would seem to make the resulting system easier to
> manage, however I can also imagine scenarios where the converse would
> be true. This is a fuzzy engineering decision of the sort that I don't
> like making without a use case---and it would be nice to have several
> here.

The SELinux provides a certain process privilege to make backups and
restore them. In the (currect) default policy, it is called "unconfined".

However, it is also *possible* to define a new special process privilege
for backup and restore tools. For example, it can access all the databse
objects and can make backups, but any other process cannot touch the
backup files. It means that DBA can launch a backup tool and it creates
a black-boxed file, then he cal also lauch a restore tool to restore
the black-boxed backup, but he cannot see the contents of the backup.
(It might be a similar idea of "sudo" mechanism.)

It is a separated issue whether the *default* security policy should
supports such an extreme protection, or not.

However, SELinux community shall provide its security policy to make
backup and restore them correctly, and suggest what privilege should
be assigned on the user sheel which launches backup and restore tools.
If it does not work correctly, it is a simply bug.

TODO: I've not provide a draft documentation for backup options to
pg_dump command, but it will be necessary to be reviewed.
It should contains what security context should be assigned on
the user shell which launches the pg_dump also.

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

Robert Haas wrote:
>>> If superusers DON'T exist, that would be making the opposite
>>> statement, namely, that there isn't ANY WAY to get a backup that you
>>> can be sure DOES contain all of the objects.
>> The traditional approach would be to maintain multiple physically
>> separate databases; in this setup it's obvious that when you perform a
>> backup of one of these databases you're only seeing a subset of "all of
>> the objects". Isn't SE-PG just allowing you to do this within a single
>> PG database?
>
> Partly. There's also a concept called "read down", which is
> important. It allows you to have, say, secret and classified data in
> the same database, and let the secret users see both types but the
> classified users see only the classified stuff, not the secret stuff.
>
> If you want to store intelligence data about the war in Iraq and
> intelligence data about the war in Afghanistan, it might not be too
> bad to store them in separate databases, though storing them in the
> same database might also make things simpler for users who have access
> to both sets of data. But if you have higher and lower
> classifications of data it's pretty handy (AIUI) to be able to let the
> higher-secrecy users read the lower-secrecy data - if you used
> separate databases to simulate read-down, you'd have to replicate data
> between them, and also have some manual mechanism for tracking which
> level of secrecy applied to which to which data.

It seems a correct description.

In addition, we also need to prevent that higher-secrecy users writes
anything to the lower-secrect objects to prevent information leaks.
In some cases, the clearance of infoamtion may be changed. We often
have dome more complex requirements also.

Thus, it is necessary a capability to store and manage data objects
with different security labeles in a single database instance here.
(If we don't want to use commercial solutions instead.)

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

On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
> Robert Haas wrote:
> >Sam Mason wrote:
> >>The traditional approach would be to maintain multiple physically
> >>separate databases; in this setup it's obvious that when you perform a
> >>backup of one of these databases you're only seeing a subset of "all of
> >>the objects". Isn't SE-PG just allowing you to do this within a single
> >>PG database?
> >
> >Partly. There's also a concept called "read down", which is
> >important. It allows you to have, say, secret and classified data in
> >the same database, and let the secret users see both types but the
> >classified users see only the classified stuff, not the secret stuff.
> >If you want to store intelligence data about the war in Iraq and
> >intelligence data about the war in Afghanistan, it might not be too
> >bad to store them in separate databases, though storing them in the
> >same database might also make things simpler for users who have access
> >to both sets of data. But if you have higher and lower
> >classifications of data it's pretty handy (AIUI) to be able to let the
> >higher-secrecy users read the lower-secrecy data - if you used
> >separate databases to simulate read-down, you'd have to replicate data
> >between them, and also have some manual mechanism for tracking which
> >level of secrecy applied to which to which data.
>
> It seems a correct description.
>
> In addition, we also need to prevent that higher-secrecy users writes
> anything to the lower-secrect objects to prevent information leaks.

OK, so to bulk out this physical analogy we'd have two physical servers
one that stores "higher-secrecy" stuff and one for "lower-secrecy"
stuff. Users with higher clearance are able to read/write the higher
secrecy database but only read the lower secrecy database. Users with
lower clearance can only read/write the lower secrecy database, ideally
they aren't even aware of the existence of the higher secrecy one.

> In some cases, the clearance of infoamtion may be changed. We often
> have dome more complex requirements also.

OK, so there is some other trusted entity that has unfettered access to
both databases and its job is to manage these requirements.

> Thus, it is necessary a capability to store and manage data objects
> with different security labeles in a single database instance here.
> (If we don't want to use commercial solutions instead.)

SE-PG is about doing the above in one database and allowing more
rigorous checks to be done?

--
Sam http://samason.me.uk/

On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
> Indeed, the draft used the term of "security context" with minimum
> introductions, but not enough friendliness for database folks.
>
> The purpose of security context is an identifier of any subject and
> object to describe them in the security policy. Because the security
> policy is common for operating system, databases, x-window and others,
> any managed database objects needs its security context.
>
> Anyway, I need to introduce them in the security model section.

I'm coming to the conclusion that you really need to link to external
material here; there must be good (and canonical) definitions of these
things outside and because SE-PG isn't self contained I really think you
need to link to them.

This will be somewhat of a break from normal PG documentation because
so far everything has been self contained, it's chosen its own
interpretation of the SQL standard and it needs to document that. SE-PG
will be interacting with much more code from outside and showing which
parts of these are PG specific vs. which parts are common to all SELinux
seems important.

If you try to document *everything* you're going to be writing for years
and give the impression that everything is implemented in SE-PG. A
dividing line needs to be drawn between what is PG specific and what is
SELinux (why not SEL?).

> For the security policy, I introduce it at the security model section:
>
> | Access control is conceptually to decide a set of allowed (or denied)
> | actions between a certain subject (such as a database client) and an
> | object (such as a table), and to apply the decision on user's requests.
> | At the database privilege system, ACL stored in database objects itself
> | holds a list of allowed actions to certain database roles, and it is
> | applied on the user's request.
> | SELinux also holds massive sets of allowed actions between a certain
> | subject and a certain object, we call them security policy.
>
> Is it obscure?

I find that somewhat opaque as well! sorry

> At this point, the SELinux user's guide in Fedora is the most comprehensive
> documentation. It is described from the viewpoint of SELinux users, not
> experts or developers.
>
> http://docs.fedoraproject.org/selinux-user-guide/

OK, thanks!

--
Sam http://samason.me.uk/

KaiGai Kohei wrote:
>
> The SELinux provides a certain process privilege to make backups and
> restore them. In the (currect) default policy, it is called "unconfined".
>
> However, it is also *possible* to define a new special process privilege
> for backup and restore tools. For example, it can access all the databse
> objects and can make backups, but any other process cannot touch the
> backup files. It means that DBA can launch a backup tool and it creates
> a black-boxed file, then he cal also lauch a restore tool to restore
> the black-boxed backup, but he cannot see the contents of the backup.
> (It might be a similar idea of "sudo" mechanism.)
>
>

Really? How you enforce this black box rule for a backup made across the
network? From the server's POV there is no such thing as a backup. All
it sees is a set of SQL statements all of which it might see in some
other context.

cheers

andrew

Sam Mason wrote:
> On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
>> Indeed, the draft used the term of "security context" with minimum
>> introductions, but not enough friendliness for database folks.
>>
>> The purpose of security context is an identifier of any subject and
>> object to describe them in the security policy. Because the security
>> policy is common for operating system, databases, x-window and others,
>> any managed database objects needs its security context.
>>
>> Anyway, I need to introduce them in the security model section.
>
> I'm coming to the conclusion that you really need to link to external
> material here; there must be good (and canonical) definitions of these
> things outside and because SE-PG isn't self contained I really think you
> need to link to them.
>
> This will be somewhat of a break from normal PG documentation because
> so far everything has been self contained, it's chosen its own
> interpretation of the SQL standard and it needs to document that. SE-PG
> will be interacting with much more code from outside and showing which
> parts of these are PG specific vs. which parts are common to all SELinux
> seems important.
>
> If you try to document *everything* you're going to be writing for years
> and give the impression that everything is implemented in SE-PG. A
> dividing line needs to be drawn between what is PG specific and what is
> SELinux (why not SEL?).

It also seems to me reasonable suggestion.

However, a reasonable amount (which should be adjusted under discussions)
of description should be self-contained.
For example, "security context is a formatted short string" is not enough
to understand why it is necessary and what is the purpose.

As Robert suggested, a few example and definition of technical terms
will help database folks to understand what it is, even if self-contained
explanation is not comprehensive from viewpoint of security folks.

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

Andrew Dunstan wrote:
>
>
> KaiGai Kohei wrote:
>>
>> The SELinux provides a certain process privilege to make backups and
>> restore them. In the (currect) default policy, it is called "unconfined".
>>
>> However, it is also *possible* to define a new special process privilege
>> for backup and restore tools. For example, it can access all the databse
>> objects and can make backups, but any other process cannot touch the
>> backup files. It means that DBA can launch a backup tool and it creates
>> a black-boxed file, then he cal also lauch a restore tool to restore
>> the black-boxed backup, but he cannot see the contents of the backup.
>> (It might be a similar idea of "sudo" mechanism.)
>>
>>
>
> Really? How you enforce this black box rule for a backup made across the
> network? From the server's POV there is no such thing as a backup. All
> it sees is a set of SQL statements all of which it might see in some
> other context.

The recent SELinux provide a feature to exchange the security context of
peer process over the network connection.
It allows to control a certain process to send/receive packets to/from
only a certain process, even if they communicate using remote connection.

This feature is named "Labeled IPsec". The key exchange daemon (racoon)
was enhanced to exchange the security context of peer processes also,
prior to the actual communications.

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

KaiGai Kohei wrote:
> Andrew Dunstan wrote:
>>
>>
>> KaiGai Kohei wrote:
>>>
>>> The SELinux provides a certain process privilege to make backups and
>>> restore them. In the (currect) default policy, it is called
>>> "unconfined".
>>>
>>> However, it is also *possible* to define a new special process
>>> privilege
>>> for backup and restore tools. For example, it can access all the
>>> databse
>>> objects and can make backups, but any other process cannot touch the
>>> backup files. It means that DBA can launch a backup tool and it creates
>>> a black-boxed file, then he cal also lauch a restore tool to restore
>>> the black-boxed backup, but he cannot see the contents of the backup.
>>> (It might be a similar idea of "sudo" mechanism.)
>>>
>>>
>>
>> Really? How you enforce this black box rule for a backup made across
>> the network? From the server's POV there is no such thing as a
>> backup. All it sees is a set of SQL statements all of which it might
>> see in some other context.
>
> The recent SELinux provide a feature to exchange the security context of
> peer process over the network connection.
> It allows to control a certain process to send/receive packets to/from
> only a certain process, even if they communicate using remote connection.
>
> This feature is named "Labeled IPsec". The key exchange daemon (racoon)
> was enhanced to exchange the security context of peer processes also,
> prior to the actual communications.
>
>

Interesting, I can see this having some use in quite a number of areas.
Of course, in the end, it still comes down to this issue, which is as
old as Plato: "Quis custodiet ipsos custodes?" (see
<http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F> )

cheers

andrew

*/

/*

Robert Haas wrote:
> If you want to store intelligence data about the war in Iraq and
> intelligence data about the war in Afghanistan, it might not be too
> bad to store them in separate databases, though storing them in the
> same database might also make things simpler for users who have access
> to both sets of data. But if you have higher and lower
> classifications of data it's pretty handy (AIUI) to be able to let the
> higher-secrecy users read the lower-secrecy data

Nice example.

Is this system being designed flexibly enough so that one user may
have access to the higher-secrecy data of the Iraq dataset but only
the lower-secrecy Afghanistan dataset; while a different user may have
access to the higher-secrecy Afghanistan data but only the lower-secrecy
Iraq data?

I imagine it's not uncommon for organizations to want to have total
access to "their" data, but expose more limited access to other
organizations they communicate with.

Andrew Dunstan wrote:
>
>
> KaiGai Kohei wrote:
>> Andrew Dunstan wrote:
>>>
>>>
>>> KaiGai Kohei wrote:
>>>>
>>>> The SELinux provides a certain process privilege to make backups and
>>>> restore them. In the (currect) default policy, it is called
>>>> "unconfined".
>>>>
>>>> However, it is also *possible* to define a new special process
>>>> privilege
>>>> for backup and restore tools. For example, it can access all the
>>>> databse
>>>> objects and can make backups, but any other process cannot touch the
>>>> backup files. It means that DBA can launch a backup tool and it creates
>>>> a black-boxed file, then he cal also lauch a restore tool to restore
>>>> the black-boxed backup, but he cannot see the contents of the backup.
>>>> (It might be a similar idea of "sudo" mechanism.)
>>>>
>>>>
>>>
>>> Really? How you enforce this black box rule for a backup made across
>>> the network? From the server's POV there is no such thing as a
>>> backup. All it sees is a set of SQL statements all of which it might
>>> see in some other context.
>>
>> The recent SELinux provide a feature to exchange the security context of
>> peer process over the network connection.
>> It allows to control a certain process to send/receive packets to/from
>> only a certain process, even if they communicate using remote connection.
>>
>> This feature is named "Labeled IPsec". The key exchange daemon (racoon)
>> was enhanced to exchange the security context of peer processes also,
>> prior to the actual communications.
>>
>>
>
> Interesting, I can see this having some use in quite a number of areas.
> Of course, in the end, it still comes down to this issue, which is as
> old as Plato: "Quis custodiet ipsos custodes?" (see
> <http://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F> )

The administrator needs to set up and manage both of the hosts to
keep consistent security policy, but it is not a technical issue.

We have security issues broader than what technical feature can solve,
and the technical security feature is a piece of them.
(Needless to say, it is an important piece.)

For example, any kind of access controls are ineffective to phisical
attacks, so we need to place the server in data centers with physical
controls on entering or leaving a room.
Referring any ISO/IEC15408 certifications, they defines a certain
environment in which the certified products to be used.
It means the certification is valid on the required environments.

The technical security feature is an important piece, but not all.

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

sam(at)samason(dot)me(dot)uk (Sam Mason) writes:
> On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
>> Robert Haas wrote:
>> In some cases, the clearance of infoamtion may be changed. We often
>> have dome more complex requirements also.
>
> OK, so there is some other trusted entity that has unfettered access to
> both databases and its job is to manage these requirements.

No, that's not what this implies.

What this implies is along the following lines...

If a user at the "more secret" level updates some data that had been
classified at a lower level, then that data gets reclassified at the
higher level.

If this sort of outcome is problematic, then that suggests that maybe
the attempt at sharing wasn't such a good idea.

>> Thus, it is necessary a capability to store and manage data objects
>> with different security labeles in a single database instance here.
>> (If we don't want to use commercial solutions instead.)
>
> SE-PG is about doing the above in one database and allowing more
> rigorous checks to be done?

I don't think the issue is so much about "more rigorous"; it's about
having mandatory labelling that is handled consistently.
--
(reverse (concatenate 'string "ofni.sesabatadxunil" "@" "enworbbc"))
http://linuxdatabases.info/info/rdbms.html
The people's revolutionary committee has decided that the name "e" is
retrogressive, unmulticious and reactionary, and has been flushed.
Please update your abbrevs.

Chris Browne wrote:
> sam(at)samason(dot)me(dot)uk (Sam Mason) writes:
>> On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
>>> Robert Haas wrote:
>>> In some cases, the clearance of infoamtion may be changed. We often
>>> have dome more complex requirements also.
>> OK, so there is some other trusted entity that has unfettered access to
>> both databases and its job is to manage these requirements.
>
> No, that's not what this implies.
>
> What this implies is along the following lines...
>
> If a user at the "more secret" level updates some data that had been
> classified at a lower level, then that data gets reclassified at the
> higher level.
>
> If this sort of outcome is problematic, then that suggests that maybe
> the attempt at sharing wasn't such a good idea.

Theoretically, such kind of updates are not visible for lower security
level users. In other word, a tuple can have multiple version depending
on the security level, it might be called as polyinstantication.

However, SE-PostgreSQL and SELinux which provides the security policy
adopt more simple solution. Its security policy prevent any "writer"
operations on the data object which dose not have identical security
level.

In other word, if the database client has "classified" level.
He cannot write anything on both of "unclassified" and "secret",
but it is possible for "classified" data object.

>>> Thus, it is necessary a capability to store and manage data objects
>>> with different security labeles in a single database instance here.
>>> (If we don't want to use commercial solutions instead.)
>> SE-PG is about doing the above in one database and allowing more
>> rigorous checks to be done?
>
> I don't think the issue is so much about "more rigorous"; it's about
> having mandatory labelling that is handled consistently.

Yes, it shall perform correctly as far as SE-PostgreSQL manages security
context of database objects and makes its access control decision without
any exceptions.

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

KaiGai --

I have a few suggestions which I will post in a bit, and some rather extensive edits of the existing Wiki, mostly for syntax rather than content.

How do you want the latter ? I can email them offline as text, or you could set me up with a login on the wiki and I could do them in place (perhaps paragraph by paragraph) ?

Thanks, and apologies for the delay !

Greg W.

ps most of what I have is orthogonal to the lively discussions since Friday.

Greg Williamson wrote:
> KaiGai --
>
> I have a few suggestions which I will post in a bit, and some
> rather extensive edits of the existing Wiki, mostly for syntax
> rather than content.
>
> How do you want the latter ? I can email them offline as text,
> or you could set me up with a login on the wiki and I could do
> them in place (perhaps paragraph by paragraph) ?

Thanks for your helps.

I think it is good idea to edit wikipage because we can easily
check and understand its update history.

IIRC, you can create a wiki account from:
http://www.postgresql.org/community/signup

BTW, I changed the structure of chapters/sections in former of
the documentation to reduce usage of undefined terminology and
so on. Sorry, if it overlapped with your efforts.
And, please note that the "3.2 Access controls" section is still
on work.

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

I revised the SE-PostgreSQL Specifications:

http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

- Put several external link to introduce something too detail
for PostgreSQL documentations.
- Paid attention not to use undefined terminology, such as
"security context", "security policy" and "mandatory access
controls".
- Revised whole of the composition in the "Brief overview" section.
- Put an example of security policy rule.
- "SECURITY_LABEL" option was replaced by "SECURITY_CONTEXT" to
avoid meaningless confusion.

I believe it become better than previous revision.

Thanks,

KaiGai Kohei wrote:
> Sam Mason wrote:
>> On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
>>> Indeed, the draft used the term of "security context" with minimum
>>> introductions, but not enough friendliness for database folks.
>>>
>>> The purpose of security context is an identifier of any subject and
>>> object to describe them in the security policy. Because the security
>>> policy is common for operating system, databases, x-window and others,
>>> any managed database objects needs its security context.
>>>
>>> Anyway, I need to introduce them in the security model section.
>>
>> I'm coming to the conclusion that you really need to link to external
>> material here; there must be good (and canonical) definitions of these
>> things outside and because SE-PG isn't self contained I really think you
>> need to link to them.
>>
>> This will be somewhat of a break from normal PG documentation because
>> so far everything has been self contained, it's chosen its own
>> interpretation of the SQL standard and it needs to document that. SE-PG
>> will be interacting with much more code from outside and showing which
>> parts of these are PG specific vs. which parts are common to all SELinux
>> seems important.
>>
>> If you try to document *everything* you're going to be writing for years
>> and give the impression that everything is implemented in SE-PG. A
>> dividing line needs to be drawn between what is PG specific and what is
>> SELinux (why not SEL?).
>
> It also seems to me reasonable suggestion.
>
> However, a reasonable amount (which should be adjusted under discussions)
> of description should be self-contained.
> For example, "security context is a formatted short string" is not enough
> to understand why it is necessary and what is the purpose.
>
> As Robert suggested, a few example and definition of technical terms
> will help database folks to understand what it is, even if self-contained
> explanation is not comprehensive from viewpoint of security folks.
>
> Thanks,

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

On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
> I'm coming to the conclusion that you really need to link to external
> material here; there must be good (and canonical) definitions of these
> things outside and because SE-PG isn't self contained I really think you
> need to link to them.

This is not supposed to be user documentation. It's supposed to be a feature
specification that an implementation can be validated against.

Thanks for the updates.

I might suggest a couple of small changes:

a) a section that explains comments like "This is not supported in the initial version" -- do you
mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ?
If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for
an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB
hackers would care if is it is not to be included. How much do these compromise the design,
and if so, are there specific plans for implementing them ?

b) something which explains the differences between SELinux and SEPostgreSQL on the one
hand (for SE fans). You've done a good job of outlining the differences and similarities with the
more standard ACL methods and that needs to be kept prominent so people with DB experience
can see the differences.

I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a
very high level outline and so I'd be tempted to move all implementation details to another page --
basically everything from ""Installation" on, with the exception of the overview of the dump issues,
is (to my eye) a detail that doesn't need exposing (yet).

I'll send mail when I have a few paragraphs done so you can check it and see if you approve.

Apologies for top-posting -- lame mailer.

Greg W.

----- Original Message ----
From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Sam Mason <sam(at)samason(dot)me(dot)uk>; pgsql-hackers(at)postgresql(dot)org
Sent: Monday, July 27, 2009 11:57:32 PM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications

I revised the SE-PostgreSQL Specifications:

http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

- Put several external link to introduce something too detail
for PostgreSQL documentations.
- Paid attention not to use undefined terminology, such as
"security context", "security policy" and "mandatory access
controls".
- Revised whole of the composition in the "Brief overview" section.
- Put an example of security policy rule.
- "SECURITY_LABEL" option was replaced by "SECURITY_CONTEXT" to
avoid meaningless confusion.

I believe it become better than previous revision.

Thanks,

KaiGai Kohei wrote:
> Sam Mason wrote:
>> On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
>>> Indeed, the draft used the term of "security context" with minimum
>>> introductions, but not enough friendliness for database folks.
>>>
>>> The purpose of security context is an identifier of any subject and
>>> object to describe them in the security policy. Because the security
>>> policy is common for operating system, databases, x-window and others,
>>> any managed database objects needs its security context.
>>>
>>> Anyway, I need to introduce them in the security model section.
>>
>> I'm coming to the conclusion that you really need to link to external
>> material here; there must be good (and canonical) definitions of these
>> things outside and because SE-PG isn't self contained I really think you
>> need to link to them.
>>
>> This will be somewhat of a break from normal PG documentation because
>> so far everything has been self contained, it's chosen its own
>> interpretation of the SQL standard and it needs to document that. SE-PG
>> will be interacting with much more code from outside and showing which
>> parts of these are PG specific vs. which parts are common to all SELinux
>> seems important.
>>
>> If you try to document *everything* you're going to be writing for years
>> and give the impression that everything is implemented in SE-PG. A
>> dividing line needs to be drawn between what is PG specific and what is
>> SELinux (why not SEL?).
>
> It also seems to me reasonable suggestion.
>
> However, a reasonable amount (which should be adjusted under discussions)
> of description should be self-contained.
> For example, "security context is a formatted short string" is not enough
> to understand why it is necessary and what is the purpose.
>
> As Robert suggested, a few example and definition of technical terms
> will help database folks to understand what it is, even if self-contained
> explanation is not comprehensive from viewpoint of security folks.
>
> Thanks,

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

On Mon, Jul 27, 2009 at 01:53:07PM -0400, Chris Browne wrote:
> sam(at)samason(dot)me(dot)uk (Sam Mason) writes:
> > On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
> >> Robert Haas wrote:
> >> In some cases, the clearance of infoamtion may be changed. We often
> >> have dome more complex requirements also.
> >
> > OK, so there is some other trusted entity that has unfettered access to
> > both databases and its job is to manage these requirements.
>
> No, that's not what this implies.
>
> What this implies is along the following lines...
>
> If a user at the "more secret" level updates some data that had been
> classified at a lower level, then that data gets reclassified at the
> higher level.

I still think it does; but maybe there are other ways of arranging
things. The problem seems to be that if each user only has write access
to their own level then the is no bound as to how far the two databases
will get out of sync with each other. Some way has to be made of
"declassifying" data and so bound the amount of difference between the
two. This declassification can not done by a normal user as they can
only write in their own level. This "trusted entity" has to exist to
punch a hole in the security to do something that wouldn't otherwise be
allowed to happen, information normally only flows "up" the hierarchy.

--
Sam http://samason.me.uk/

[wretched top-posting -- begs forgiveness!]

KaiGai --

I have edited the first three sections (up to but not including "Architecture"), mostly cleaning up language but I did run into a few places where I am not sure if I got the proper meaning -- I flagged those in square brackets (e.g.[...]) and with your name. Feel free to change them, accept them, or confer back with me about them.

In particular, in the Security policy section you had:
>

> TE rules use the third field in the security context. It is called type or domain (for processes).
> allow httpd_t sepgsql_ro_table_t : db_table {getattr select lock};

I thought that colons were used to split these fields, so the above line would have only 2 ? Perhaps after the httpd_t ?

I'd like to get some feedback from you (and any other readers) before I do more ... I need to go deal an invasion of the kitchen -- it is garbage collection morning (early) and I just had a pretty young skunk and two raccoon kits in rapid order and I have to clean up and secure the premises.

Regards!

G

----- Original Message ----
From: Greg Williamson <gwilliamson39(at)yahoo(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>; KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Sam Mason <sam(at)samason(dot)me(dot)uk>; pgsql-hackers(at)postgresql(dot)org
Sent: Tuesday, July 28, 2009 1:20:29 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications

Thanks for the updates.

I might suggest a couple of small changes:

a) a section that explains comments like "This is not supported in the initial version" -- do you
mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ?
If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for
an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB
hackers would care if is it is not to be included. How much do these compromise the design,
and if so, are there specific plans for implementing them ?

b) something which explains the differences between SELinux and SEPostgreSQL on the one
hand (for SE fans). You've done a good job of outlining the differences and similarities with the
more standard ACL methods and that needs to be kept prominent so people with DB experience
can see the differences.

I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a
very high level outline and so I'd be tempted to move all implementation details to another page --
basically everything from ""Installation" on, with the exception of the overview of the dump issues,
is (to my eye) a detail that doesn't need exposing (yet).

I'll send mail when I have a few paragraphs done so you can check it and see if you approve.

Apologies for top-posting -- lame mailer.

Greg W.

----- Original Message ----
From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Sam Mason <sam(at)samason(dot)me(dot)uk>; pgsql-hackers(at)postgresql(dot)org
Sent: Monday, July 27, 2009 11:57:32 PM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications

I revised the SE-PostgreSQL Specifications:

http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft

- Put several external link to introduce something too detail
for PostgreSQL documentations.
- Paid attention not to use undefined terminology, such as
"security context", "security policy" and "mandatory access
controls".
- Revised whole of the composition in the "Brief overview" section.
- Put an example of security policy rule.
- "SECURITY_LABEL" option was replaced by "SECURITY_CONTEXT" to
avoid meaningless confusion.

I believe it become better than previous revision.

Thanks,

KaiGai Kohei wrote:
> Sam Mason wrote:
>> On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
>>> Indeed, the draft used the term of "security context" with minimum
>>> introductions, but not enough friendliness for database folks.
>>>
>>> The purpose of security context is an identifier of any subject and
>>> object to describe them in the security policy. Because the security
>>> policy is common for operating system, databases, x-window and others,
>>> any managed database objects needs its security context.
>>>
>>> Anyway, I need to introduce them in the security model section.
>>
>> I'm coming to the conclusion that you really need to link to external
>> material here; there must be good (and canonical) definitions of these
>> things outside and because SE-PG isn't self contained I really think you
>> need to link to them.
>>
>> This will be somewhat of a break from normal PG documentation because
>> so far everything has been self contained, it's chosen its own
>> interpretation of the SQL standard and it needs to document that. SE-PG
>> will be interacting with much more code from outside and showing which
>> parts of these are PG specific vs. which parts are common to all SELinux
>> seems important.
>>
>> If you try to document *everything* you're going to be writing for years
>> and give the impression that everything is implemented in SE-PG. A
>> dividing line needs to be drawn between what is PG specific and what is
>> SELinux (why not SEL?).
>
> It also seems to me reasonable suggestion.
>
> However, a reasonable amount (which should be adjusted under discussions)
> of description should be self-contained.
> For example, "security context is a formatted short string" is not enough
> to understand why it is necessary and what is the purpose.
>
> As Robert suggested, a few example and definition of technical terms
> will help database folks to understand what it is, even if self-contained
> explanation is not comprehensive from viewpoint of security folks.
>
> Thanks,

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Peter Eisentraut wrote:
> On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
>> I'm coming to the conclusion that you really need to link to external
>> material here; there must be good (and canonical) definitions of these
>> things outside and because SE-PG isn't self contained I really think you
>> need to link to them.
>
> This is not supposed to be user documentation. It's supposed to be a feature
> specification that an implementation can be validated against.
>

Hmm...
What kind of descriptions are necessary for a feature specifications?

Currently, I guess the specification describes when/where the security
hook should be invoked, what permission should be checked and what result
should be returned for each security hooks.

Is it correct? Or, do you expect any other stuffs?

Apart from that, user documentation is also necessary.
If the specification should be described from completely different viewpoint,
I'll provide it.

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

Greg Williamson wrote:
> [wretched top-posting -- begs forgiveness!]
>
> KaiGai --
>
> I have edited the first three sections (up to but not including "Architecture"),
> mostly cleaning up language but I did run into a few places where I am not
> sure if I got the proper meaning -- I flagged those in square brackets
(e.g.[...])
> and with your name. Feel free to change them, accept them, or confer back with me
> about them.

Thanks for your efforts so much.
I'll confirm it tomorrow (in JST).

> In particular, in the Security policy section you had:
>
>> TE rules use the third field in the security context. It is called type or domain (for processes).
>> allow httpd_t sepgsql_ro_table_t : db_table {getattr select lock};
>
> I thought that colons were used to split these fields, so the above line would
> have only 2 ? Perhaps after the httpd_t ?

It says the third field in the security policy, not a rule in the security
policy. Sorry, it might be introduced more carefully.

In the default security policy, web server process performs labeled as
"system_u:system_r:httpd_t:s0".
^^^^^^^
This rule is checked when web server process tries to access a table labeled
as "system_u:object_r:sepgsql_ro_table_t:s0", for example.
^^^^^^^^^^^^^^^^^^
The TE rule is defined between the pair of third field (which is called type
or domain) of security contexts.

# BTW, basically, the second field is used for RBAC rules, the fourth field
# is used for MLS rules. The first field is used to record who create the
# object.

Thanks,

>
>
> I'd like to get some feedback from you (and any other readers) before I do more ... I need to go deal an invasion of the kitchen -- it is garbage collection morning (early) and I just had a pretty young skunk and two raccoon kits in rapid order and I have to clean up and secure the premises.
>
> Regards!
>
> G
>
>
>
> ----- Original Message ----
> From: Greg Williamson <gwilliamson39(at)yahoo(dot)com>
> To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>; KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
> Cc: Sam Mason <sam(at)samason(dot)me(dot)uk>; pgsql-hackers(at)postgresql(dot)org
> Sent: Tuesday, July 28, 2009 1:20:29 AM
> Subject: Re: [HACKERS] SE-PostgreSQL Specifications
>
>
> Thanks for the updates.
>
> I might suggest a couple of small changes:
>
> a) a section that explains comments like "This is not supported in the initial version" -- do you
> mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ?
> If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for
> an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB
> hackers would care if is it is not to be included. How much do these compromise the design,
> and if so, are there specific plans for implementing them ?
>
> b) something which explains the differences between SELinux and SEPostgreSQL on the one
> hand (for SE fans). You've done a good job of outlining the differences and similarities with the
> more standard ACL methods and that needs to be kept prominent so people with DB experience
> can see the differences.
>
> I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a
> very high level outline and so I'd be tempted to move all implementation details to another page --
> basically everything from ""Installation" on, with the exception of the overview of the dump issues,
> is (to my eye) a detail that doesn't need exposing (yet).
>
> I'll send mail when I have a few paragraphs done so you can check it and see if you approve.
>
> Apologies for top-posting -- lame mailer.
>
> Greg W.
>
>
>
>
> ----- Original Message ----
> From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
> To: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
> Cc: Sam Mason <sam(at)samason(dot)me(dot)uk>; pgsql-hackers(at)postgresql(dot)org
> Sent: Monday, July 27, 2009 11:57:32 PM
> Subject: Re: [HACKERS] SE-PostgreSQL Specifications
>
> I revised the SE-PostgreSQL Specifications:
>
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
>
> - Put several external link to introduce something too detail
> for PostgreSQL documentations.
> - Paid attention not to use undefined terminology, such as
> "security context", "security policy" and "mandatory access
> controls".
> - Revised whole of the composition in the "Brief overview" section.
> - Put an example of security policy rule.
> - "SECURITY_LABEL" option was replaced by "SECURITY_CONTEXT" to
> avoid meaningless confusion.
>
> I believe it become better than previous revision.
>
> Thanks,
>
> KaiGai Kohei wrote:
>> Sam Mason wrote:
>>> On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
>>>> Indeed, the draft used the term of "security context" with minimum
>>>> introductions, but not enough friendliness for database folks.
>>>>
>>>> The purpose of security context is an identifier of any subject and
>>>> object to describe them in the security policy. Because the security
>>>> policy is common for operating system, databases, x-window and others,
>>>> any managed database objects needs its security context.
>>>>
>>>> Anyway, I need to introduce them in the security model section.
>>> I'm coming to the conclusion that you really need to link to external
>>> material here; there must be good (and canonical) definitions of these
>>> things outside and because SE-PG isn't self contained I really think you
>>> need to link to them.
>>>
>>> This will be somewhat of a break from normal PG documentation because
>>> so far everything has been self contained, it's chosen its own
>>> interpretation of the SQL standard and it needs to document that. SE-PG
>>> will be interacting with much more code from outside and showing which
>>> parts of these are PG specific vs. which parts are common to all SELinux
>>> seems important.
>>>
>>> If you try to document *everything* you're going to be writing for years
>>> and give the impression that everything is implemented in SE-PG. A
>>> dividing line needs to be drawn between what is PG specific and what is
>>> SELinux (why not SEL?).
>> It also seems to me reasonable suggestion.
>>
>> However, a reasonable amount (which should be adjusted under discussions)
>> of description should be self-contained.
>> For example, "security context is a formatted short string" is not enough
>> to understand why it is necessary and what is the purpose.
>>
>> As Robert suggested, a few example and definition of technical terms
>> will help database folks to understand what it is, even if self-contained
>> explanation is not comprehensive from viewpoint of security folks.
>>
>> Thanks,
>
>

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

On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote:
> Peter Eisentraut wrote:
> > On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
> >> I'm coming to the conclusion that you really need to link to external
> >> material here; there must be good (and canonical) definitions of these
> >> things outside and because SE-PG isn't self contained I really think you
> >> need to link to them.
> >
> > This is not supposed to be user documentation. It's supposed to be a
> > feature specification that an implementation can be validated against.
>
> Hmm...
> What kind of descriptions are necessary for a feature specifications?

It describes what the feature does and why.

> Currently, I guess the specification describes when/where the security
> hook should be invoked, what permission should be checked and what result
> should be returned for each security hooks.
>
> Is it correct? Or, do you expect any other stuffs?

That is a pretty good start, but it's drifting into implementation details.

> Apart from that, user documentation is also necessary.
> If the specification should be described from completely different
> viewpoint, I'll provide it.

Yes, user documentation will eventually also be necessary, and the original
specification may be usable as a source for that. I'm just reacting to those
who commented whether or not references should be added and what reference
style the documentation uses. We're not there yet. The purpose of this
document is to explain what the feature does, not to teach users to use the
feature.

Greg Williamson wrote:
> Thanks for the updates.
>
> I might suggest a couple of small changes:
>
> a) a section that explains comments like "This is not supported in the initial version" -- do you
> mean in the first Beta release of SE-PostgreSQL, or not in the initial release(s) for commitfests ?
> If it is not supported why mention it ? If experienced users of SELinux expect it, they might look for
> an explanation as to why it is missing and when it might appear. I'm not sure if postgres DB
> hackers would care if is it is not to be included. How much do these compromise the design,
> and if so, are there specific plans for implementing them ?

The "This is not supported ..." comment means this feature is not included within
the initial patch submitted to the next commit fest, so the corresponding section
is not also included within the documentation patch at that time.
However, I expect all the features and corresponding user documents should be
included within the stable v8.5 release. So, I also described these sections
with notations.

> b) something which explains the differences between SELinux and SEPostgreSQL on the one
> hand (for SE fans). You've done a good job of outlining the differences and similarities with the
> more standard ACL methods and that needs to be kept prominent so people with DB experience
> can see the differences.
>
> I am all in favor of external links if you can find good explanation of concepts elsewhere. This is a
> very high level outline and so I'd be tempted to move all implementation details to another page --
> basically everything from ""Installation" on, with the exception of the overview of the dump issues,
> is (to my eye) a detail that doesn't need exposing (yet).

At first, what should be included within the PostgreSQL official documentation?

I don't think here is any opposition to include
- Steps to installations
- Enhancement in SQL statement
- External links something like:
"It provides mandatory access controls. See the http://..... for details."

Needs to be discussed
- Securtiy model overview, such as security context, security policy and so on.
- Feature overview, such as example of access controls.
- References to object classes and permissions.
(Basically, it is not necessary for end users.)

If we prepare a comprehensive external documentation, one idea is to revise
the series of wikipages at:

http://wiki.postgresql.org/wiki/SEPostgreSQL

Thanks,

> I'll send mail when I have a few paragraphs done so you can check it and see if you approve.
>
> Apologies for top-posting -- lame mailer.
>
> Greg W.
>
>
>
>
> ----- Original Message ----
> From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
> To: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
> Cc: Sam Mason <sam(at)samason(dot)me(dot)uk>; pgsql-hackers(at)postgresql(dot)org
> Sent: Monday, July 27, 2009 11:57:32 PM
> Subject: Re: [HACKERS] SE-PostgreSQL Specifications
>
> I revised the SE-PostgreSQL Specifications:
>
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
>
> - Put several external link to introduce something too detail
> for PostgreSQL documentations.
> - Paid attention not to use undefined terminology, such as
> "security context", "security policy" and "mandatory access
> controls".
> - Revised whole of the composition in the "Brief overview" section.
> - Put an example of security policy rule.
> - "SECURITY_LABEL" option was replaced by "SECURITY_CONTEXT" to
> avoid meaningless confusion.
>
> I believe it become better than previous revision.
>
> Thanks,
>
> KaiGai Kohei wrote:
>> Sam Mason wrote:
>>> On Sun, Jul 26, 2009 at 12:27:12PM +0900, KaiGai Kohei wrote:
>>>> Indeed, the draft used the term of "security context" with minimum
>>>> introductions, but not enough friendliness for database folks.
>>>>
>>>> The purpose of security context is an identifier of any subject and
>>>> object to describe them in the security policy. Because the security
>>>> policy is common for operating system, databases, x-window and others,
>>>> any managed database objects needs its security context.
>>>>
>>>> Anyway, I need to introduce them in the security model section.
>>> I'm coming to the conclusion that you really need to link to external
>>> material here; there must be good (and canonical) definitions of these
>>> things outside and because SE-PG isn't self contained I really think you
>>> need to link to them.
>>>
>>> This will be somewhat of a break from normal PG documentation because
>>> so far everything has been self contained, it's chosen its own
>>> interpretation of the SQL standard and it needs to document that. SE-PG
>>> will be interacting with much more code from outside and showing which
>>> parts of these are PG specific vs. which parts are common to all SELinux
>>> seems important.
>>>
>>> If you try to document *everything* you're going to be writing for years
>>> and give the impression that everything is implemented in SE-PG. A
>>> dividing line needs to be drawn between what is PG specific and what is
>>> SELinux (why not SEL?).
>> It also seems to me reasonable suggestion.
>>
>> However, a reasonable amount (which should be adjusted under discussions)
>> of description should be self-contained.
>> For example, "security context is a formatted short string" is not enough
>> to understand why it is necessary and what is the purpose.
>>
>> As Robert suggested, a few example and definition of technical terms
>> will help database folks to understand what it is, even if self-contained
>> explanation is not comprehensive from viewpoint of security folks.
>>
>> Thanks,
>
>

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

Peter Eisentraut wrote:
> On Tuesday 28 July 2009 15:36:29 KaiGai Kohei wrote:
>> Peter Eisentraut wrote:
>>> On Sunday 26 July 2009 14:35:41 Sam Mason wrote:
>>>> I'm coming to the conclusion that you really need to link to external
>>>> material here; there must be good (and canonical) definitions of these
>>>> things outside and because SE-PG isn't self contained I really think you
>>>> need to link to them.
>>> This is not supposed to be user documentation. It's supposed to be a
>>> feature specification that an implementation can be validated against.
>> Hmm...
>> What kind of descriptions are necessary for a feature specifications?
>
> It describes what the feature does and why.
>
>> Currently, I guess the specification describes when/where the security
>> hook should be invoked, what permission should be checked and what result
>> should be returned for each security hooks.
>>
>> Is it correct? Or, do you expect any other stuffs?
>
> That is a pretty good start, but it's drifting into implementation details.
>
>> Apart from that, user documentation is also necessary.
>> If the specification should be described from completely different
>> viewpoint, I'll provide it.
>
> Yes, user documentation will eventually also be necessary, and the original
> specification may be usable as a source for that. I'm just reacting to those
> who commented whether or not references should be added and what reference
> style the documentation uses. We're not there yet. The purpose of this
> document is to explain what the feature does, not to teach users to use the
> feature.

For a couple of days, I have paid my efforts to provide the design
specifications more than user documentations.
(But a few sections are under construction.)

http://wiki.postgresql.org/wiki/SEPostgreSQL_Development

Some of sections are copied from the SEPostgreSQL_Draft and edited,
rest of sections are also revised to represent its feature and behavior
more correctly.

At the current moment, I can agree it is too early to discuss the style
for user documentation. So, I would like to freeze the efforts to the
user documentation for a while, and begin to discuss the design specification
which focuses on developers.

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

As Peter Eisentraut pointed out, we are not on the phase
to discuss about user documentations yet.

It is a reasonable idea to discuss correct specifications
of SE-PostgreSQL from the viewpoint of the developers.
Then, it will the a good source for the upcoming user docs.

For the recent a few days, I've worked to write and edit
the specification (partially copied from the draft of user
documentation) for the development purpose.

http://wiki.postgresql.org/wiki/SEPostgreSQL_Development

I would like to have a discussion for its design specifications
and make clear anything unclear for pgsql folks (including the
quality of English).

Because this wikipage intends to provide the specifications
from the viewpoint of developers, it describes features more
detailed than the user visible documentation.

I intended to describe the features correctly, but it does not
mean perfect, needless to say.
Please feel free to ask / point out me, if something unclear or
not-easy understandable.

Thanks,

KaiGai Kohei wrote:
> Here is the initial draft of SE-PostgreSQL specifications:
>
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Draft
>
> I've described it from the scratch again with paying attention
> for the people knowing nothing about SELinux.
> In some points, it uses comparison between the database privilege
> mechanism and SE-PostgreSQL for easy understanding.
>
> Please point out, if ...
> - Its composition can be improved.
> - Here is not enough introductions for what user wants to know.
> - Here is too much explanations, more brief one will be available.
> - Here is not easy understandable for database folks.
> - Here is not enough English quality.
> - And so on...
>
> In addition, I would like to fix its specifications during the discussion.
>
> Thanks,

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

KaiGai,

* KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
> For the recent a few days, I've worked to write and edit
> the specification (partially copied from the draft of user
> documentation) for the development purpose.
>
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Development

Thanks for doing this. I've taken a quick glance through it and will
review it more later today. The next step, I believe, is to document
the changes which need to be made to PG, at a high level, to support
this specification.

I think the initial goal should be to make changes mainly to aclchk.c to
add the SELinux hooks. I'd like to hear from some committers about this
idea: I think we should also be looking to move more of the permissions
checking which is done in other parts of the code (eg:
ATExecChangeOwner()) into aclchk.c, which is where I would argue it
belongs. Doing so will make it much easier to add other hooks, should
the need arise, and would minimize the amount of code 'touched' to add
SELinux support.

Strategy for code changes:
Patch #1: Move permissions checks currently implemented in other parts
of the code (eg: tablecmds.c:ATExecChangeOwner()) into
aclchk.c.
Patch #2: Change the aclchk.c function APIs, if necessary, to add
additional information required for SELinux (eg: the 'old'
owner).
Patch #3: Add SELinux hooks into aclchk.c functions.

This initial round, again, should focus on just those
controls/permissions which PostgreSQL already supports. At this time,
do not stress over finding every "if(superuser())" and moving it to
aclchk.c. Let's deal with the "clear" situations, such as tablecmds.c
lines 6322-6342 (that entire block, including the if(!superuser()),
should be ripped out and made a function in aclchk.c which is called
with necessary args). We can go back and "clean up" the other places
where we have explicit superuser() checks later, if necessary.

I've finally had a chance to look through the last set of proposed
patches some, and I've noticed some other issues that need to be
addressed:

- Let's avoid the changes to heaptuple.c for now. That's really for
much later down the road when we implement row-level security.
- I would expect the dependency system to be used to handle deleting
things from pg_security, etc, when an object has been deleted (eg: a
table was dropped).
- Conversly, when new entries need to be added to pg_security, they
should be done at the same level as other items being added to the
catalog. In places like createdb(), where it's all one big function,
I would recommend splitting out the existing catalog update into a
separate function, which then makes it much clearer that the code is
doing: update pg_database table, update pg_security table, update
pg_dependency table. That should be done as a separate patch, of
course. Remember, we're trying to make small incremental changes that
make sense by themselves but at the same time will reduce the effort
required to add SELinux later.
- In terms of cacheing the results, is there any way we could use
SysCache for this? And just handle the cacheing in the hooks, etc,
from aclchk.c? I dislike having the security labels added to
every tuple until we actually implement row level security. It adds
alot of unnecessary complexity to the initial implementation.
Note that I'm referring to the results from the kernel/syscalls, I
realize you're using SysCache properly for the entries in pg_security
already, and that's good.

Guess that's a start on the implementation design, which I feel is the
next step after specification. Perhaps you could start a wiki page on
it which includes my comments? I'm in meetings for the next couple of
hours, but will resume looking at this after lunch, US/Eastern time.

Thanks,

Stephen

Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> For the recent a few days, I've worked to write and edit
>> the specification (partially copied from the draft of user
>> documentation) for the development purpose.
>>
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Development
>
> Thanks for doing this. I've taken a quick glance through it and will
> review it more later today. The next step, I believe, is to document
> the changes which need to be made to PG, at a high level, to support
> this specification.

Thanks for your help.

I also think it is necessary to describe what changes are needed on
the core pgsql except for security routines.

It is just an example:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#security_hooks_.28example.29

I believe such kind of specifications are necessary at the next.

> I think the initial goal should be to make changes mainly to aclchk.c to
> add the SELinux hooks. I'd like to hear from some committers about this
> idea: I think we should also be looking to move more of the permissions
> checking which is done in other parts of the code (eg:
> ATExecChangeOwner()) into aclchk.c, which is where I would argue it
> belongs. Doing so will make it much easier to add other hooks, should
> the need arise, and would minimize the amount of code 'touched' to add
> SELinux support.
>
> Strategy for code changes:
> Patch #1: Move permissions checks currently implemented in other parts
> of the code (eg: tablecmds.c:ATExecChangeOwner()) into
> aclchk.c.
> Patch #2: Change the aclchk.c function APIs, if necessary, to add
> additional information required for SELinux (eg: the 'old'
> owner).
> Patch #3: Add SELinux hooks into aclchk.c functions.

Thanks for your idea. However, it seems to me this approach eventually
requires bigger changeset than what the current security hooks doing.
In addition, it cannot solve the differences in behavior due to the
security model on which they stand.

For example, when we create a new table, the native database privilege
mechanism checks its permission on the schema object which the new
table blongs to. On the other hand, SELinux requires to check
"db_table:{create}" permission on the newly created table itself.

In my understanding, the purpose of the design specification is to make
clear for database folks what the security hooks doin and why the security
hooks are deployed here.

Linux kernel is a good case in success.
Needless to say, most of kernel developer are not security experts.
But they defined an explicit specification of the security hooks called
LSM, and put these hooks on the strategic points in the kernel.
(The very long source code comments describes what is the purpose of this
security hook, what arguments should be given and so on for each security
hooks.)

> This initial round, again, should focus on just those
> controls/permissions which PostgreSQL already supports. At this time,
> do not stress over finding every "if(superuser())" and moving it to
> aclchk.c. Let's deal with the "clear" situations, such as tablecmds.c
> lines 6322-6342 (that entire block, including the if(!superuser()),
> should be ripped out and made a function in aclchk.c which is called
> with necessary args). We can go back and "clean up" the other places
> where we have explicit superuser() checks later, if necessary.

At least, it works correctly as far as the native database privilege
mechanism. If the specification of the security hooks is clear, I think
the following manner is better than modifying DAC mechanism.

if (!superuser())
{
if (pg_xxx_aclcheck(....) != ACLCHECK_OK)
aclcheck_error(....);
}
+ sepgsqlCheckXXXX();

> I've finally had a chance to look through the last set of proposed
> patches some, and I've noticed some other issues that need to be
> addressed:
>
> - Let's avoid the changes to heaptuple.c for now. That's really for
> much later down the road when we implement row-level security.

Yes, I can agree to postpone pg_security and corresponding facilities
until row-level security.

> - I would expect the dependency system to be used to handle deleting
> things from pg_security, etc, when an object has been deleted (eg: a
> table was dropped).

In the patch for v8.4.x series (with fullset functionality), it is
already implemented. Any entries within pg_security referenced by the
dropped table is reclaimed, when we drop a table.
The matter of orphan entries are already solved.

> - Conversly, when new entries need to be added to pg_security, they
> should be done at the same level as other items being added to the
> catalog. In places like createdb(), where it's all one big function,
> I would recommend splitting out the existing catalog update into a
> separate function, which then makes it much clearer that the code is
> doing: update pg_database table, update pg_security table, update
> pg_dependency table. That should be done as a separate patch, of
> course. Remember, we're trying to make small incremental changes that
> make sense by themselves but at the same time will reduce the effort
> required to add SELinux later.

Sorry, it's unclear for me what you would like to explain...

However, I can agree the step-by-step approach on development.
The design specification describes an "ideal image" of SE-PostgreSQL.
I understand several phases are necessary to come up to the stage.

> - In terms of cacheing the results, is there any way we could use
> SysCache for this? And just handle the cacheing in the hooks, etc,
> from aclchk.c? I dislike having the security labels added to
> every tuple until we actually implement row level security. It adds
> alot of unnecessary complexity to the initial implementation.
> Note that I'm referring to the results from the kernel/syscalls, I
> realize you're using SysCache properly for the entries in pg_security
> already, and that's good.

In the current fullset version, I uses SysCache facility to translate
between security identifier (Oid) and security context (text).
It should be implemented as a part of pg_security and corresponding
facilities.

What does the "cacheing the results" mean?
If you talked about the caches of access control decision, it is quite
different thing from SysCache mechanism. It intends to reduce the number
of kernel invocation, not the number of database lookups.

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

KaiGai,

* KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
> Stephen Frost wrote:
> > Strategy for code changes:
> > Patch #1: Move permissions checks currently implemented in other parts
> > of the code (eg: tablecmds.c:ATExecChangeOwner()) into
> > aclchk.c.
> > Patch #2: Change the aclchk.c function APIs, if necessary, to add
> > additional information required for SELinux (eg: the 'old'
> > owner).
> > Patch #3: Add SELinux hooks into aclchk.c functions.
>
> Thanks for your idea. However, it seems to me this approach eventually
> requires bigger changeset than what the current security hooks doing.

Yes, it almost certainly will. However, this is really the approach
that I think we need to take. I think what we're beginning to
understand, collectivly, is something that some of the committers, etc,
have been saying all along- implementing SELinux in PG requires alot
more changes to PG than just sprinkling hooks all over the code. This
is because we want to do it right, for PG, and for our users.

What this means is that we need to improve the PG code first. Then,
when we're happy with those changes, we can add the SELinux hooks and be
comfortable that they will operate correctly, do what they're intended
to, and also allow us to extend the system further for the "next big
privileges thing", if that happens some day.

> In addition, it cannot solve the differences in behavior due to the
> security model on which they stand.
>
> For example, when we create a new table, the native database privilege
> mechanism checks its permission on the schema object which the new
> table blongs to. On the other hand, SELinux requires to check
> "db_table:{create}" permission on the newly created table itself.

That's fine. We implement a function in aclchk.c which is essentially
"pg_createTablePriv(schema,newtable)". The logic for doing the check is
moved out of tablecmds.c (or where ever) and into that function. We can
then easily add to that function the SELinux hook. Is there some issue
here which I'm not seeing? If so, can you please clarify?

Also, I don't see "db_table:{create}" in the documentation anywhere.
There is a "db_schema:{add_name}", is that what you're referring to?
How would you check the permissions on an object (and how or why would
they be different than the default, unless that's also being handled at
the creation time) which is in the process of being created?

> In my understanding, the purpose of the design specification is to make
> clear for database folks what the security hooks doin and why the security
> hooks are deployed here.

I don't think we're going to have much buy-in or success sprinkling
these hooks all over the PG source code. It would make maintenance a
real problem for the PG folks and for those of us trying to work with
SE. The SELinux hooks really need to be folded into PG's existing
authentication system, and if that system needs to be improved or
expanded, then that's what it requires.

> Linux kernel is a good case in success.
> Needless to say, most of kernel developer are not security experts.
> But they defined an explicit specification of the security hooks called
> LSM, and put these hooks on the strategic points in the kernel.
> (The very long source code comments describes what is the purpose of this
> security hook, what arguments should be given and so on for each security
> hooks.)

Right, we have a number of these already, and they are represented by
the aclchk.c functions. The problem that SELinux points out is that
we've not been consistant with having aclchk.c do the permissions
checking. Specifically on the "simple" stuff where we currently require
owner rights. What we need to do is improve PG by pulling those checks
out of the areas they are, spread all around the code, and consolidating
them into aclchk.c (or a new file if that is deisred). We're not going
to get anywhere by trying to add on more hooks all over the code.

> > This initial round, again, should focus on just those
> > controls/permissions which PostgreSQL already supports. At this time,
> > do not stress over finding every "if(superuser())" and moving it to
> > aclchk.c. Let's deal with the "clear" situations, such as tablecmds.c
> > lines 6322-6342 (that entire block, including the if(!superuser()),
> > should be ripped out and made a function in aclchk.c which is called
> > with necessary args). We can go back and "clean up" the other places
> > where we have explicit superuser() checks later, if necessary.
>
> At least, it works correctly as far as the native database privilege
> mechanism. If the specification of the security hooks is clear, I think
> the following manner is better than modifying DAC mechanism.
>
> if (!superuser())
> {
> if (pg_xxx_aclcheck(....) != ACLCHECK_OK)
> aclcheck_error(....);
> }
> + sepgsqlCheckXXXX();

Again, this would mean dropping sepgsql() calls all over the code,
because we don't currently have all of these permission checks done in
one place. We need to first consoldiate the permission checks and then
add the sepgsql() hooks *there*.

> > I've finally had a chance to look through the last set of proposed
> > patches some, and I've noticed some other issues that need to be
> > addressed:
> >
> > - Let's avoid the changes to heaptuple.c for now. That's really for
> > much later down the road when we implement row-level security.
>
> Yes, I can agree to postpone pg_security and corresponding facilities
> until row-level security.

We might flip this around and use pg_security to track the labels on the
catalog entries, rather than modifying every catalog table... That was
my first thought anyway.

> > - I would expect the dependency system to be used to handle deleting
> > things from pg_security, etc, when an object has been deleted (eg: a
> > table was dropped).
>
> In the patch for v8.4.x series (with fullset functionality), it is
> already implemented. Any entries within pg_security referenced by the
> dropped table is reclaimed, when we drop a table.
> The matter of orphan entries are already solved.

Not correctly, which is what I'm complaining about here. Right now
there's a "sepgsqlDropTable" or "sepgsqlDropDB" call or some such in the
middle of the "dropTable" or "dropDB" command. Those shouldn't be
necessary, I don't think, if the dependency system is being properly
used. I might be up a tree here, but I'd like to think I'm not. Those
hooks should be called from the dependency system, not from the
'droptable' command.

> > - Conversly, when new entries need to be added to pg_security, they
> > should be done at the same level as other items being added to the
> > catalog. In places like createdb(), where it's all one big function,
> > I would recommend splitting out the existing catalog update into a
> > separate function, which then makes it much clearer that the code is
> > doing: update pg_database table, update pg_security table, update
> > pg_dependency table. That should be done as a separate patch, of
> > course. Remember, we're trying to make small incremental changes that
> > make sense by themselves but at the same time will reduce the effort
> > required to add SELinux later.
>
> Sorry, it's unclear for me what you would like to explain...

The catalog update I'm referring to is the long list of
MemSet(new_record)
new_record[blah] = blah
new_record[blah] = blah
new_record[blah] = blah
new_record[blah] = blah
new_record[blah] = blah
etc, etc

I would move that out into it's own function (addDBCatalog?). Then we
can more cleanly add the "recordSElabel()" function to the overall
createdb() function. This is refactoring things to improve PG.

> However, I can agree the step-by-step approach on development.
> The design specification describes an "ideal image" of SE-PostgreSQL.
> I understand several phases are necessary to come up to the stage.

Exactly...

> What does the "cacheing the results" mean?
> If you talked about the caches of access control decision, it is quite
> different thing from SysCache mechanism. It intends to reduce the number
> of kernel invocation, not the number of database lookups.

It's still a cache, and if we have a cacheing facility already in place,
it'd be nice to reuse it rather than adding a whole new one. Perhaps it
can be extended to support what you need to cache the access control
decisions?

Thanks,

Stephen

On Fri, Jul 31, 2009 at 5:13 PM, Stephen Frost<sfrost(at)snowman(dot)net> wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
>> Stephen Frost wrote:
>> > Strategy for code changes:
>> >   Patch #1: Move permissions checks currently implemented in other parts
>> >             of the code (eg: tablecmds.c:ATExecChangeOwner()) into
>> >                     aclchk.c.
>> >   Patch #2: Change the aclchk.c function APIs, if necessary, to add
>> >             additional information required for SELinux (eg: the 'old'
>> >                     owner).
>> >   Patch #3: Add SELinux hooks into aclchk.c functions.
>>
>> Thanks for your idea. However, it seems to me this approach eventually
>> requires bigger changeset than what the current security hooks doing.
>
> Yes, it almost certainly will.  However, this is really the approach
> that I think we need to take.  I think what we're beginning to
> understand, collectivly, is something that some of the committers, etc,
> have been saying all along- implementing SELinux in PG requires alot
> more changes to PG than just sprinkling hooks all over the code.  This
> is because we want to do it right, for PG, and for our users.
>
> What this means is that we need to improve the PG code first.  Then,
> when we're happy with those changes, we can add the SELinux hooks and be
> comfortable that they will operate correctly, do what they're intended
> to, and also allow us to extend the system further for the "next big
> privileges thing", if that happens some day.
>
>> In addition, it cannot solve the differences in behavior due to the
>> security model on which they stand.
>>
>> For example, when we create a new table, the native database privilege
>> mechanism checks its permission on the schema object which the new
>> table blongs to. On the other hand, SELinux requires to check
>> "db_table:{create}" permission on the newly created table itself.
>
> That's fine.  We implement a function in aclchk.c which is essentially
> "pg_createTablePriv(schema,newtable)".  The logic for doing the check is
> moved out of tablecmds.c (or where ever) and into that function.  We can
> then easily add to that function the SELinux hook.  Is there some issue
> here which I'm not seeing?  If so, can you please clarify?
>
> Also, I don't see "db_table:{create}" in the documentation anywhere.
> There is a "db_schema:{add_name}", is that what you're referring to?
> How would you check the permissions on an object (and how or why would
> they be different than the default, unless that's also being handled at
> the creation time) which is in the process of being created?
>
>> In my understanding, the purpose of the design specification is to make
>> clear for database folks what the security hooks doin and why the security
>> hooks are deployed here.
>
> I don't think we're going to have much buy-in or success sprinkling
> these hooks all over the PG source code.  It would make maintenance a
> real problem for the PG folks and for those of us trying to work with
> SE.  The SELinux hooks really need to be folded into PG's existing
> authentication system, and if that system needs to be improved or
> expanded, then that's what it requires.
>
>> Linux kernel is a good case in success.
>> Needless to say, most of kernel developer are not security experts.
>> But they defined an explicit specification of the security hooks called
>> LSM, and put these hooks on the strategic points in the kernel.
>> (The very long source code comments describes what is the purpose of this
>> security hook, what arguments should be given and so on for each security
>> hooks.)
>
> Right, we have a number of these already, and they are represented by
> the aclchk.c functions.  The problem that SELinux points out is that
> we've not been consistant with having aclchk.c do the permissions
> checking.  Specifically on the "simple" stuff where we currently require
> owner rights.  What we need to do is improve PG by pulling those checks
> out of the areas they are, spread all around the code, and consolidating
> them into aclchk.c (or a new file if that is deisred).  We're not going
> to get anywhere by trying to add on more hooks all over the code.
>
>> > This initial round, again, should focus on just those
>> > controls/permissions which PostgreSQL already supports.  At this time,
>> > do not stress over finding every "if(superuser())" and moving it to
>> > aclchk.c.  Let's deal with the "clear" situations, such as tablecmds.c
>> > lines 6322-6342 (that entire block, including the if(!superuser()),
>> > should be ripped out and made a function in aclchk.c which is called
>> > with necessary args).  We can go back and "clean up" the other places
>> > where we have explicit superuser() checks later, if necessary.
>>
>> At least, it works correctly as far as the native database privilege
>> mechanism. If the specification of the security hooks is clear, I think
>> the following manner is better than modifying DAC mechanism.
>>
>>   if (!superuser())
>>   {
>>       if (pg_xxx_aclcheck(....) != ACLCHECK_OK)
>>           aclcheck_error(....);
>>   }
>> + sepgsqlCheckXXXX();
>
> Again, this would mean dropping sepgsql() calls all over the code,
> because we don't currently have all of these permission checks done in
> one place.  We need to first consoldiate the permission checks and then
> add the sepgsql() hooks *there*.
>
>> > I've finally had a chance to look through the last set of proposed
>> > patches some, and I've noticed some other issues that need to be
>> > addressed:
>> >
>> > - Let's avoid the changes to heaptuple.c for now.  That's really for
>> >   much later down the road when we implement row-level security.
>>
>> Yes, I can agree to postpone pg_security and corresponding facilities
>> until row-level security.
>
> We might flip this around and use pg_security to track the labels on the
> catalog entries, rather than modifying every catalog table...  That was
> my first thought anyway.
>
>> > - I would expect the dependency system to be used to handle deleting
>> >   things from pg_security, etc, when an object has been deleted (eg: a
>> >   table was dropped).
>>
>> In the patch for v8.4.x series (with fullset functionality), it is
>> already implemented. Any entries within pg_security referenced by the
>> dropped table is reclaimed, when we drop a table.
>> The matter of orphan entries are already solved.
>
> Not correctly, which is what I'm complaining about here.  Right now
> there's a "sepgsqlDropTable" or "sepgsqlDropDB" call or some such in the
> middle of the "dropTable" or "dropDB" command.  Those shouldn't be
> necessary, I don't think, if the dependency system is being properly
> used.  I might be up a tree here, but I'd like to think I'm not.  Those
> hooks should be called from the dependency system, not from the
> 'droptable' command.
>
>> > - Conversly, when new entries need to be added to pg_security, they
>> >   should be done at the same level as other items being added to the
>> >   catalog.  In places like createdb(), where it's all one big function,
>> >   I would recommend splitting out the existing catalog update into a
>> >   separate function, which then makes it much clearer that the code is
>> >   doing: update pg_database table, update pg_security table, update
>> >   pg_dependency table.  That should be done as a separate patch, of
>> >   course.  Remember, we're trying to make small incremental changes that
>> >   make sense by themselves but at the same time will reduce the effort
>> >   required to add SELinux later.
>>
>> Sorry, it's unclear for me what you would like to explain...
>
> The catalog update I'm referring to is the long list of
> MemSet(new_record)
> new_record[blah] = blah
> new_record[blah] = blah
> new_record[blah] = blah
> new_record[blah] = blah
> new_record[blah] = blah
> etc, etc
>
> I would move that out into it's own function (addDBCatalog?).  Then we
> can more cleanly add the "recordSElabel()" function to the overall
> createdb() function.  This is refactoring things to improve PG.
>
>> However, I can agree the step-by-step approach on development.
>> The design specification describes an "ideal image" of SE-PostgreSQL.
>> I understand several phases are necessary to come up to the stage.
>
> Exactly...
>
>> What does the "cacheing the results" mean?
>> If you talked about the caches of access control decision, it is quite
>> different thing from SysCache mechanism. It intends to reduce the number
>> of kernel invocation, not the number of database lookups.
>
> It's still a cache, and if we have a cacheing facility already in place,
> it'd be nice to reuse it rather than adding a whole new one.  Perhaps it
> can be extended to support what you need to cache the access control
> decisions?
>
>        Thanks,
>
>                Stephen

FWIW, pretty much +1 from me on everything in here; I think this is
definitely going in the right direction. It's not the size of the
patches that matter; it's the complexity and difficulty of verifying
that they don't break anything. And it's not cumulative: three easy
patches are better than one hard one, as long as they're really
self-contained.

The idea of restructuring the aclcheck mechanism to support sepgsql
is, IMO, brilliant.

...Robert

Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
>> Stephen Frost wrote:
>>> Strategy for code changes:
>>> Patch #1: Move permissions checks currently implemented in other parts
>>> of the code (eg: tablecmds.c:ATExecChangeOwner()) into
>>> aclchk.c.
>>> Patch #2: Change the aclchk.c function APIs, if necessary, to add
>>> additional information required for SELinux (eg: the 'old'
>>> owner).
>>> Patch #3: Add SELinux hooks into aclchk.c functions.
>> Thanks for your idea. However, it seems to me this approach eventually
>> requires bigger changeset than what the current security hooks doing.
>
> Yes, it almost certainly will. However, this is really the approach
> that I think we need to take. I think what we're beginning to
> understand, collectivly, is something that some of the committers, etc,
> have been saying all along- implementing SELinux in PG requires alot
> more changes to PG than just sprinkling hooks all over the code. This
> is because we want to do it right, for PG, and for our users.
>
> What this means is that we need to improve the PG code first. Then,
> when we're happy with those changes, we can add the SELinux hooks and be
> comfortable that they will operate correctly, do what they're intended
> to, and also allow us to extend the system further for the "next big
> privileges thing", if that happens some day.

When I scraped the idea of PGACE framework, someone (IIRC, Robert Haas) asked
me whether it is possible to implement the native database privilege mechanism
on the PGACE, or not.
It seems to me your suggestion is similar to the idea of PGACE framework.
But, note that it does not mean I criticize your idea.

Let's consider the matter more using a few examples.

Example 1) ALTER TABLE xxx
The native database privilege mechanism checks the ownership of the target
table to control the ALTER TABLE. On the other hand, SE-PgSQL checks the
db_table:{setattr} permission on the target table to control the ALTER TABLE.

I believe you can notice both of checks have same purpose but differences are
on the criterions. It is the way to make their decisions in other word.

The pg_xxx_aclcheck() interfaces provide the way to make its access control
decision. The core PG code calls pg_xxx_aclcheck() to achieve its purpose
which is to apply access controls on ALTER TABLE.

Accordingly, if we avoid to put SE-PgSQL's security hooks on the tablecmd.c
directly, what we should do is to inject an abstraction layer between tablecmd.c
and aclchk.c.

For example:
void pg_security_alter_table(Oid relid)
{
if (!pg_class_ownercheck(relid, GetUserId())
aclcheck_error(...);

if (!sepgsqlCheckTableSetattr(relid))
selinux_error(...);
}

Example 2) DROP TABLE xxx

The native database privilege mechanism also checks the ownership of the target
table to be dropped (except for cascaded deletion).
However, SELinux want to apply db_table:{drop} permission, instead of db_table:{setattr}.
It is obvious that pg_class_ownercheck() cannot be a caller of the SELinux's
security hook.

It should be:
void pg_security_drop_table(Oid relid)
{
if (!pg_class_ownercheck(relid, GetUserId())
ackcheck_error(...);

if (!sepgsqlCheckTableDrop(relid))
selinux_error(...);
}

Example 3) ACL_EXECUTE

The ACL_EXECUTE permission is checked on the runtime and setup time.
The meaning of runtime is obvious. It should be checked when user's query tries to
execute a function.
For example, CreateConversionCommand() checks ACL_EXECUTE when user tries to create
a new conversion. It is available for all the users.
However, SELinux want to apply different permissions for runtime and installation time.

On the runtime of the function, it applies db_procedure:{execute}.
On the installation time, it applies db_procedure:{install}.
Because a user defined function is installed as a part of system internals,
it is available for every users. SELinux considers it is fundamentally different
from a user can run a function defined myself.

Because the topic is a bit abstract, it is not clear whether I can introduce
what I want to say correctly, or not.
Please feel free to ask me, if something unclear.

>> In addition, it cannot solve the differences in behavior due to the
>> security model on which they stand.
>>
>> For example, when we create a new table, the native database privilege
>> mechanism checks its permission on the schema object which the new
>> table blongs to. On the other hand, SELinux requires to check
>> "db_table:{create}" permission on the newly created table itself.
>
> That's fine. We implement a function in aclchk.c which is essentially
> "pg_createTablePriv(schema,newtable)". The logic for doing the check is
> moved out of tablecmds.c (or where ever) and into that function. We can
> then easily add to that function the SELinux hook. Is there some issue
> here which I'm not seeing? If so, can you please clarify?
>
> Also, I don't see "db_table:{create}" in the documentation anywhere.
> There is a "db_schema:{add_name}", is that what you're referring to?
> How would you check the permissions on an object (and how or why would
> they be different than the default, unless that's also being handled at
> the creation time) which is in the process of being created?

It is described at:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Common_object_behavior

When we create a new table, SELinux's mode requires all the following
permissions individually.
- db_schema:{add_name}, because a table is created under a certain schema
- db_table:{create} due to the common object behavior
- db_column:{create} for each columns, due to the common object behavior

Note that the newly created object does not exist when SE-PgSQL checks its
db_xxx:{create} permission.
Accordingly, it computes a default security context (if user gives nothing)
to be assigned on the new object, and it checks db_xxx:{create} permission
toward the context. Then, it returns the security context to the caller.

>> In my understanding, the purpose of the design specification is to make
>> clear for database folks what the security hooks doin and why the security
>> hooks are deployed here.
>
> I don't think we're going to have much buy-in or success sprinkling
> these hooks all over the PG source code. It would make maintenance a
> real problem for the PG folks and for those of us trying to work with
> SE. The SELinux hooks really need to be folded into PG's existing
> authentication system, and if that system needs to be improved or
> expanded, then that's what it requires.

As I mentioned above, if (enhanced) PG's access control mechanism can
contain all the needed SELinux hooks, I can agree to put security hooks
inside the PG's security.
However, note that I have a legitimate reason that we cannot put SELinux
hooks inside the *current* pg_xxx_aclcheck() routines, to implement the
security model of SELinux correctly.

Anyway, if we put security hooks inside from the common strategic points,
we need one more abstraction layer for access controls.

If we reconstruct the current PG's access control, it is necessary.

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

Robert Haas wrote:
> FWIW, pretty much +1 from me on everything in here; I think this is
> definitely going in the right direction. It's not the size of the
> patches that matter; it's the complexity and difficulty of verifying
> that they don't break anything. And it's not cumulative: three easy
> patches are better than one hard one, as long as they're really
> self-contained.
>
> The idea of restructuring the aclcheck mechanism to support sepgsql
> is, IMO, brilliant.

As I noted in the reply to Stephen Frost, "what should be controled"
(e.g, ALTER TABLE) and "how to check it" (e.g, ownership based control)
are different things.

If we go on the direction to restructure the current aclcheck mechanism
and to integrate entry points of security features into a single file,
I really really want an implementation independent layer which focuses
on access controls.

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

KaiGai,

* KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
> It seems to me your suggestion is similar to the idea of PGACE framework.

It is, but it's being done as incremental changes to the existing
structures, and working with them, instead of ignoring that they exist.

> Let's consider the matter more using a few examples.
>
> Example 1) ALTER TABLE xxx
> The native database privilege mechanism checks the ownership of the target
> table to control the ALTER TABLE. On the other hand, SE-PgSQL checks the
> db_table:{setattr} permission on the target table to control the ALTER TABLE.
>
> I believe you can notice both of checks have same purpose but differences are
> on the criterions. It is the way to make their decisions in other word.
>
> The pg_xxx_aclcheck() interfaces provide the way to make its access control
> decision. The core PG code calls pg_xxx_aclcheck() to achieve its purpose
> which is to apply access controls on ALTER TABLE.
>
> Accordingly, if we avoid to put SE-PgSQL's security hooks on the tablecmd.c
> directly, what we should do is to inject an abstraction layer between tablecmd.c
> and aclchk.c.
>
> For example:
> void pg_security_alter_table(Oid relid)
> {
> if (!pg_class_ownercheck(relid, GetUserId())
> aclcheck_error(...);
>
> if (!sepgsqlCheckTableSetattr(relid))
> selinux_error(...);
> }

Right, something along these lines, where the function lives in aclchk.c
and is part of its overall API. This also shows pretty clearly how, if
we needed to add other hooks into the permissions for this operation, we
could do so. It also shows how we could *first* build:

void pg_security_alter_table(Oid relid)
{
if (!pg_class_ownercheck(relid, GetUserId())
aclcheck_error(...);
}

and make the corresponding changes in tablecmds.c, etc, and do that as a
separate patch. Once that's done, we can review it, test it, etc, as
just an incremental change to PG. This should be much easier/faster to
review as a patch as well, and to convince ourselves that we havn't
broken PG's current security (which is an extremely critical thing).
Additionally, when we then come back and add SELinux hooks, they will be
done in an isolated area and be additions to a system which has been
made to support such an extension.

> Example 2) DROP TABLE xxx
>
> The native database privilege mechanism also checks the ownership of the target
> table to be dropped (except for cascaded deletion).
> However, SELinux want to apply db_table:{drop} permission, instead of db_table:{setattr}.
> It is obvious that pg_class_ownercheck() cannot be a caller of the SELinux's
> security hook.
>
> It should be:
> void pg_security_drop_table(Oid relid)
> {
> if (!pg_class_ownercheck(relid, GetUserId())
> ackcheck_error(...);
>
> if (!sepgsqlCheckTableDrop(relid))
> selinux_error(...);
> }

Right. Similar to above.

> Example 3) ACL_EXECUTE
>
> The ACL_EXECUTE permission is checked on the runtime and setup time.
> The meaning of runtime is obvious. It should be checked when user's query tries to
> execute a function.
> For example, CreateConversionCommand() checks ACL_EXECUTE when user tries to create
> a new conversion. It is available for all the users.
> However, SELinux want to apply different permissions for runtime and installation time.
>
> On the runtime of the function, it applies db_procedure:{execute}.
> On the installation time, it applies db_procedure:{install}.
> Because a user defined function is installed as a part of system internals,
> it is available for every users. SELinux considers it is fundamentally different
> from a user can run a function defined myself.

I'm not sure I follow how this is dramatically different from the other
examples. We have checks in place in PG already at both runtime of the
function (user has 'execute' privilege) and at creation time (functions
are created in schemas, after all). If there are checks that PG doesn't
do today but which SELinux wants, those can be added too.. But as we've
discussed, that should be postponed until we get this initial structure
in place to allow PG to be extensible in this way.

> Because the topic is a bit abstract, it is not clear whether I can introduce
> what I want to say correctly, or not.
> Please feel free to ask me, if something unclear.

Yeah, I don't entirely get what you're trying to say here. Perhaps you
could try and rephrase it?

> It is described at:
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Common_object_behavior
>
> When we create a new table, SELinux's mode requires all the following
> permissions individually.
> - db_schema:{add_name}, because a table is created under a certain schema
> - db_table:{create} due to the common object behavior
> - db_column:{create} for each columns, due to the common object behavior
>
> Note that the newly created object does not exist when SE-PgSQL checks its
> db_xxx:{create} permission.
> Accordingly, it computes a default security context (if user gives nothing)
> to be assigned on the new object, and it checks db_xxx:{create} permission
> toward the context. Then, it returns the security context to the caller.

That sounds like it should all be possible to do through the mechanism
I'm suggesting..

> As I mentioned above, if (enhanced) PG's access control mechanism can
> contain all the needed SELinux hooks, I can agree to put security hooks
> inside the PG's security.
> However, note that I have a legitimate reason that we cannot put SELinux
> hooks inside the *current* pg_xxx_aclcheck() routines, to implement the
> security model of SELinux correctly.

Sure, and that's fine. I think the problem that you keep running into
is this: You don't want to touch the PG code too much for fear of the
patch being too big, but at the same time, what you need really should
be implemented by making those changes to the core code.

We're not afraid of making large scale changes to core. It just needs
to be done incrementally and done *first*, before adding features and
code which depends on it. We have to fix PG *first*, in this regard,
before we can even start to look at SELinux hooks, etc.

Thanks,

Stephen

* KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
> As I noted in the reply to Stephen Frost, "what should be controled"
> (e.g, ALTER TABLE) and "how to check it" (e.g, ownership based control)
> are different things.
>
> If we go on the direction to restructure the current aclcheck mechanism
> and to integrate entry points of security features into a single file,
> I really really want an implementation independent layer which focuses
> on access controls.

I think that's what I'm advocating.. If, by that, you mean we should do
it in a separate file from aclchk.c, I'm not against that. It would
likely mean moving some things *from* aclchk.c into it, and then just
using aclchk.c for "helpers" to support the PG permissions. I'm not
sure which way would be "easier" to handle in terms of patch review,
etc..

Thanks,

Stephen

Stephen Frost wrote:
>> For example:
>> void pg_security_alter_table(Oid relid)
>> {
>> if (!pg_class_ownercheck(relid, GetUserId())
>> aclcheck_error(...);
>>
>> if (!sepgsqlCheckTableSetattr(relid))
>> selinux_error(...);
>> }
>
> Right, something along these lines, where the function lives in aclchk.c
> and is part of its overall API. This also shows pretty clearly how, if
> we needed to add other hooks into the permissions for this operation, we
> could do so. It also shows how we could *first* build:
>
> void pg_security_alter_table(Oid relid)
> {
> if (!pg_class_ownercheck(relid, GetUserId())
> aclcheck_error(...);
> }
>
> and make the corresponding changes in tablecmds.c, etc, and do that as a
> separate patch. Once that's done, we can review it, test it, etc, as
> just an incremental change to PG. This should be much easier/faster to
> review as a patch as well, and to convince ourselves that we havn't
> broken PG's current security (which is an extremely critical thing).
> Additionally, when we then come back and add SELinux hooks, they will be
> done in an isolated area and be additions to a system which has been
> made to support such an extension.

Basically, I can agree this approach.
However, it is necessary to consider the idea deeply whether it is really
possible to implement the SELinux's model correctly, or not.

For example, ExecCheckRTEPerms() checks permissions on DML statement.
It allows users to access required table and columns, if he has appropriate
permissions on the table OR all the columns in use.
But SELinux requires the client needs to be allowed on the table AND all
the columns in use.

Please note that all we need to focus on is not pg_xxx_aclcheck() routines
in other words.

>> Example 3) ACL_EXECUTE
>>
>> The ACL_EXECUTE permission is checked on the runtime and setup time.
>> The meaning of runtime is obvious. It should be checked when user's query tries to
>> execute a function.
>> For example, CreateConversionCommand() checks ACL_EXECUTE when user tries to create
>> a new conversion. It is available for all the users.
>> However, SELinux want to apply different permissions for runtime and installation time.
>>
>> On the runtime of the function, it applies db_procedure:{execute}.
>> On the installation time, it applies db_procedure:{install}.
>> Because a user defined function is installed as a part of system internals,
>> it is available for every users. SELinux considers it is fundamentally different
>> from a user can run a function defined myself.
>
> I'm not sure I follow how this is dramatically different from the other
> examples. We have checks in place in PG already at both runtime of the
> function (user has 'execute' privilege) and at creation time (functions
> are created in schemas, after all). If there are checks that PG doesn't
> do today but which SELinux wants, those can be added too.. But as we've
> discussed, that should be postponed until we get this initial structure
> in place to allow PG to be extensible in this way.

What I would like to say was how does the user defined function is used.
(However, it is the issue corresponding to the security model, not where
we should put the security hooks.)

For example, type input/output handlers are invoked without permission
checks on runtime. We never see an error due to the lack of permission
to execute textout() function. The native privilege model assumes type
input/output handlers can be trusted, because only superuser can set up
own types. (In fact, DefineType() checks superuser() at the head.)

So, rest of the routine does not check anything based on the assumption
of the superuser. See the #ifdef NOT_USER ... #endif block in DefineType().

It looks like the native database privilege mechanism does not check such
a permission, however, it implicitly assume ACL_EXECUTE permission is
always allowed for superuser.

Here, it seems to me ACL_EXECUTE has two different meanings here.
The one is obvious. It is a privilege a certain user to execute a certain
function in his query. The other is a privilege a certain user allows
everyone to execute a certain a part of the system internal stuff
(such as type input/output handlers).

The example is not dramatically different from the others, indeed.
But, this code implicitly assume the database superuser can do anyhting,
so the necessary checks are omitted from the code (because they always
return "allowed").

I think it is also necessary to follow these implicit permission check.

>> As I mentioned above, if (enhanced) PG's access control mechanism can
>> contain all the needed SELinux hooks, I can agree to put security hooks
>> inside the PG's security.
>> However, note that I have a legitimate reason that we cannot put SELinux
>> hooks inside the *current* pg_xxx_aclcheck() routines, to implement the
>> security model of SELinux correctly.
>
> Sure, and that's fine. I think the problem that you keep running into
> is this: You don't want to touch the PG code too much for fear of the
> patch being too big, but at the same time, what you need really should
> be implemented by making those changes to the core code.
>
> We're not afraid of making large scale changes to core. It just needs
> to be done incrementally and done *first*, before adding features and
> code which depends on it. We have to fix PG *first*, in this regard,
> before we can even start to look at SELinux hooks, etc.

At this time, this approach seems to me reasonable.

I think what I should do on the next is ...
- To check up whether it is really possible to implement SELinux's model.
- To describe the list of the security functions in the new abstraction layer.
- To discuss the list of permission at:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls

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

KaiGai,

* KaiGai Kohei (kaigai(at)kaigai(dot)gr(dot)jp) wrote:
> Please note that all we need to focus on is not pg_xxx_aclcheck() routines
> in other words.

I agree, there may be other things which need to move to aclchk.c, and
that routine is a good example of something which would be appropriate
to move, abstract, and provide an SELinux hook for, in aclchk.c.

> The example is not dramatically different from the others, indeed.
> But, this code implicitly assume the database superuser can do anyhting,
> so the necessary checks are omitted from the code (because they always
> return "allowed").

Yes, I realize that's a problem. I don't know that it's a problem which
has to be addressed in the first round, but I do believe we will get
there.

> I think what I should do on the next is ...
> - To check up whether it is really possible to implement SELinux's model.
> - To describe the list of the security functions in the new abstraction layer.
> - To discuss the list of permission at:
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls

That sounds like a good approach. As we define the security functions
to go into the abstraction layer, I would also say we should identify
the exact pieces of existing code which are going to move.

Thanks,

Stephen

Stephen Frost wrote:
>> I think what I should do on the next is ...
>> - To check up whether it is really possible to implement SELinux's model.
>> - To describe the list of the security functions in the new abstraction layer.
>> - To discuss the list of permission at:
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls
>
> That sounds like a good approach. As we define the security functions
> to go into the abstraction layer, I would also say we should identify
> the exact pieces of existing code which are going to move.

I began to describe the list of abstraction layer functions (but not completed yet):
http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction

In my current impression, it indeed requires a few kilo lines of changes,
but it is not impossible scale.

I now plans to submit two patches for the next commit fest.
The one is implementation of the abstraction layer.
The other is basic implementation of the SE-PostgreSQL.

So, I would like to fix external specification at least.

The specifications for developer notes definitions of permissions:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Development

As Robert suggested before, I plans to support access controls on the
following database objects and permissions at the first stage.
* databases
* schemas
* tables
* columns
* sequences
* functions
* tablespaces

Do you have any comment for the directions?

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

KaiGai --

I was pulled away from any work on this for a few days ... what can I do to help, if anything ? (Keeping in mind that my knowledge of the internals of postgres is, alas, minimal.) ... I had a quick look at this new page and want to take another, more careful, look.

The sheer scope of this proposal undoubtedly gives pause to many, so I'd urge a certain minimalism at first to prove that the concept works and doesn't damage the core functionality at all when it is not used (fairly straight forward). Eventually rough measures of the performance hit when it is used will be useful, but users will expect something of a slow-down, I suspect, in exchange foe the greater security.

To that end, I am wondering if there is test data yet designed ? Are there prescribed tests (I remember seeing some but they seem to be buried in months/threads that I have not yet re-dicsovered) ? I have some experience doing QA and could perhaps also help in these, a little.

And let me add, I am in awe of your efforts on this !

G

----- Original Message ----
From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>; Robert Haas <robertmhaas(at)gmail(dot)com>; pgsql-hackers(at)postgresql(dot)org; Greg Williamson <gwilliamson39(at)yahoo(dot)com>; Sam Mason <sam(at)samason(dot)me(dot)uk>; Joshua Brindle <method(at)manicmethod(dot)com>
Sent: Monday, August 3, 2009 12:09:45 AM
Subject: Re: [HACKERS] SE-PostgreSQL Specifications

Stephen Frost wrote:
>> I think what I should do on the next is ...
>> - To check up whether it is really possible to implement SELinux's model.
>> - To describe the list of the security functions in the new abstraction layer.
>> - To discuss the list of permission at:
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls
>
> That sounds like a good approach. As we define the security functions
> to go into the abstraction layer, I would also say we should identify
> the exact pieces of existing code which are going to move.

I began to describe the list of abstraction layer functions (but not completed yet):
http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction

In my current impression, it indeed requires a few kilo lines of changes,
but it is not impossible scale.

I now plans to submit two patches for the next commit fest.
The one is implementation of the abstraction layer.
The other is basic implementation of the SE-PostgreSQL.

So, I would like to fix external specification at least.

The specifications for developer notes definitions of permissions:
http://wiki.postgresql.org/wiki/SEPostgreSQL_Development

As Robert suggested before, I plans to support access controls on the
following database objects and permissions at the first stage.
* databases
* schemas
* tables
* columns
* sequences
* functions
* tablespaces

Do you have any comment for the directions?

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

Greg Williamson wrote:
> KaiGai --
>
> I was pulled away from any work on this for a few days ... what can I do
> to help, if anything ? (Keeping in mind that my knowledge of the internals
> of postgres is, alas, minimal.) ... I had a quick look at this new page and
> want to take another, more careful, look.

I got a few reasonable sugegstions at the last week.
The one is it is important to provide a design specification from the viewpoint
of developers to make clear what features are provided by SE-PostgreSQL, and
it will be a good source for the official documentation for users.
The other is a suggestion corresponding to the way to implement it. Its conclusion
was to inject an abstraction layer to support multiple security models at first.

I guess Robert concerned about my English quality in the documentation patch
contained in the proposed patch set at first. In same time, lack of design
specification was pointed out. It also should be provided prior to the patch
to make clear what is identical to/different from the native database privilege
mechanism.

Both of them are documentations. But these have their own purpose, target and
style to be required. It might be a causion of the confusion.

In my current opinion, we should have a discussion corresponding to the design
specifications and internals, and implement it prior to the user documentation.

So, I would like you to give me the time to conclude the design specifications
and to implement patches for the next commit fest.

> The sheer scope of this proposal undoubtedly gives pause to many, so I'd urge
> a certain minimalism at first to prove that the concept works and doesn't damage
> the core functionality at all when it is not used (fairly straight forward).
> Eventually rough measures of the performance hit when it is used will be useful,
> but users will expect something of a slow-down, I suspect, in exchange foe the
> greater security.

Are you talking about what the user documentation should include, aren't you?
Indeed, I also think these items should be introduced.

> To that end, I am wondering if there is test data yet designed ? Are there
> prescribed tests (I remember seeing some but they seem to be buried in
> months/threads that I have not yet re-dicsovered) ? I have some experience doing
> QA and could perhaps also help in these, a little.

I also provided a patch for the testcases of SE-PostgreSQL.

For example:
http://code.google.com/p/sepgsql/source/browse/tags/sepgsql/src/test/sepgsql

Thanks,

> And let me add, I am in awe of your efforts on this !
>
> G
>
>
>
> ----- Original Message ----
> From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
> To: Stephen Frost <sfrost(at)snowman(dot)net>
> Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>; Robert Haas <robertmhaas(at)gmail(dot)com>; pgsql-hackers(at)postgresql(dot)org; Greg Williamson <gwilliamson39(at)yahoo(dot)com>; Sam Mason <sam(at)samason(dot)me(dot)uk>; Joshua Brindle <method(at)manicmethod(dot)com>
> Sent: Monday, August 3, 2009 12:09:45 AM
> Subject: Re: [HACKERS] SE-PostgreSQL Specifications
>
> Stephen Frost wrote:
>>> I think what I should do on the next is ...
>>> - To check up whether it is really possible to implement SELinux's model.
>>> - To describe the list of the security functions in the new abstraction layer.
>>> - To discuss the list of permission at:
>>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Development#Mandatory_access_controls
>> That sounds like a good approach. As we define the security functions
>> to go into the abstraction layer, I would also say we should identify
>> the exact pieces of existing code which are going to move.
>
> I began to describe the list of abstraction layer functions (but not completed yet):
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
>
> In my current impression, it indeed requires a few kilo lines of changes,
> but it is not impossible scale.
>
> I now plans to submit two patches for the next commit fest.
> The one is implementation of the abstraction layer.
> The other is basic implementation of the SE-PostgreSQL.
>
> So, I would like to fix external specification at least.
>
> The specifications for developer notes definitions of permissions:
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Development
>
> As Robert suggested before, I plans to support access controls on the
> following database objects and permissions at the first stage.
> * databases
> * schemas
> * tables
> * columns
> * sequences
> * functions
> * tablespaces
>
> Do you have any comment for the directions?
>
> Thanks,

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

2009/8/3 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> I now plans to submit two patches for the next commit fest.
> The one is implementation of the abstraction layer.
> The other is basic implementation of the SE-PostgreSQL.

Is this a good idea, or would it be better to focus on the aclcheck
stuff (which is what I understand you to mean here by abstraction
layer) first? You will be much happier getting one patch committed
than two patches not committed... getting two patches of this size in
one CommitFest seems very unlikely, and I worry that the SE-PostgreSQL
patch will distract your time and reviewing time from the aclcheck
refactoring that must get done first, and well.

...Robert

Robert Haas wrote:
> 2009/8/3 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> I now plans to submit two patches for the next commit fest.
>> The one is implementation of the abstraction layer.
>> The other is basic implementation of the SE-PostgreSQL.
>
> Is this a good idea, or would it be better to focus on the aclcheck
> stuff (which is what I understand you to mean here by abstraction
> layer) first? You will be much happier getting one patch committed
> than two patches not committed... getting two patches of this size in
> one CommitFest seems very unlikely, and I worry that the SE-PostgreSQL
> patch will distract your time and reviewing time from the aclcheck
> refactoring that must get done first, and well.

Needless to say, the security abstraction layer shall have higher
priority than SE-PostgreSQL which depends on the layer.

If we can focus on the SE-PostgreSQL feature in the third commit fest,
it will be better than all the facilities from the scratch.
(BTW, I also have a WIP patch to support largeobject permissions.)

So, we may be able to modify the development plan as follows:
* 2nd CommitFest (15-Sep)
- security abstraction layer
(- largeobject permission)

* 3rd CommitFest (15-Nov)
- basic functionality of SE-PostgreSQL

* 4th CommitFest (15-Jan)
- full functionality of SE-PostgreSQL
(row-level controls, filesystem permissions, ...)

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

KaiGai,

* KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
> So, we may be able to modify the development plan as follows:
> * 2nd CommitFest (15-Sep)
> - security abstraction layer
> (- largeobject permission)
>
> * 3rd CommitFest (15-Nov)
> - basic functionality of SE-PostgreSQL
>
> * 4th CommitFest (15-Jan)
> - full functionality of SE-PostgreSQL
> (row-level controls, filesystem permissions, ...)

Not to throw water on this right from the get-go, but I think getting
the security abstraction and basic SE-PostgreSQL functionality (based on
existing PG permissions) into 8.5 will be enough of a stretch.
row-level security needs to be implement in PG proper first, before we
can add the SE-PG hooks for it. That's going to be a serious amount of
work by itself, and is something which is extremely unlikely to make
sense to commit that late in the cycle.

Let's focus on improving aclchk.c to the point where SE-PG can be
easily added without dropping hooks all over the place. If we can get
that into 8.5 it will be a huge success. We can then work on row-level
permissions for 8.6, first as a PG-native feature, and then with SE-PG
hooks.

Thanks,

Stephen

Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> So, we may be able to modify the development plan as follows:
>> * 2nd CommitFest (15-Sep)
>> - security abstraction layer
>> (- largeobject permission)
>>
>> * 3rd CommitFest (15-Nov)
>> - basic functionality of SE-PostgreSQL
>>
>> * 4th CommitFest (15-Jan)
>> - full functionality of SE-PostgreSQL
>> (row-level controls, filesystem permissions, ...)
>
> Not to throw water on this right from the get-go, but I think getting
> the security abstraction and basic SE-PostgreSQL functionality (based on
> existing PG permissions) into 8.5 will be enough of a stretch.
> row-level security needs to be implement in PG proper first, before we
> can add the SE-PG hooks for it. That's going to be a serious amount of
> work by itself, and is something which is extremely unlikely to make
> sense to commit that late in the cycle.

It seems to me it is a bit early to conclude what feature will be
included into 8.5 and what feature is not so.
The above plan is a very rough sketch.
Anyway, what I would like to say is I can agree to focus on the security
abstraction layer earlier than SE-PostgreSQL feature.

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

KaiGai,

* KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
> I began to describe the list of abstraction layer functions (but not completed yet):
> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction

I'm not really a huge fan of 'security_' as a prefix for these
functions, but I don't have a better suggestion right now.

The initial abstraction patch shouldn't include the security context
pieces. I realize that will be needed eventually, but the patch to do
the abstraction and to formally move permissions checking to aclchk.c
needs to stand alone. I'm also not sure that the API of having the
security context be returned as a Datum makes sense..

Doesn't security_table_permissions() need to know if the query is an
UPDATE or an INSERT?

Thanks,

Stephen

On Mon, Aug 3, 2009 at 10:19 PM, Stephen Frost<sfrost(at)snowman(dot)net> wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> So, we may be able to modify the development plan as follows:
>> * 2nd CommitFest (15-Sep)
>>  - security abstraction layer
>> (- largeobject permission)
>>
>> * 3rd CommitFest (15-Nov)
>>  - basic functionality of SE-PostgreSQL
>>
>> * 4th CommitFest (15-Jan)
>>  - full functionality of SE-PostgreSQL
>>    (row-level controls, filesystem permissions, ...)
>
> Not to throw water on this right from the get-go, but I think getting
> the security abstraction and basic SE-PostgreSQL functionality (based on
> existing PG permissions) into 8.5 will be enough of a stretch.
> row-level security needs to be implement in PG proper first, before we
> can add the SE-PG hooks for it.  That's going to be a serious amount of
> work by itself, and is something which is extremely unlikely to make
> sense to commit that late in the cycle.

+1. Optimism is good, realism is better.

> Let's focus on improving aclchk.c to the point where SE-PG can be
> easily added without dropping hooks all over the place.  If we can get
> that into 8.5 it will be a huge success.  We can then work on row-level
> permissions for 8.6, first as a PG-native feature, and then with SE-PG
> hooks.

Row-level security is going to be a very, very difficult feature to
implement properly. A lot of thought is needed here to design
something good.

...Robert

Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> I began to describe the list of abstraction layer functions (but not completed yet):
>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
>
> I'm not really a huge fan of 'security_' as a prefix for these
> functions, but I don't have a better suggestion right now.

If so, 'pgsec_' (PostGresql SECutiry) instead?

> The initial abstraction patch shouldn't include the security context
> pieces. I realize that will be needed eventually, but the patch to do
> the abstraction and to formally move permissions checking to aclchk.c
> needs to stand alone. I'm also not sure that the API of having the
> security context be returned as a Datum makes sense..

OK, I'll add pieces corresponding to the security context on the second
patch (SE-PostgreSQL patch).

> Doesn't security_table_permissions() need to know if the query is an
> UPDATE or an INSERT?

Either ACL_UPDATE or ACL_INSERT should be set on the required_perms.
Both of them are never set in same time.

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

On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
> > I began to describe the list of abstraction layer functions (but not completed yet):
> > http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
>
> I'm not really a huge fan of 'security_' as a prefix for these
> functions, but I don't have a better suggestion right now.

Just generally, "access control" is a great way to describe what's
actually happening here. That people conflate access control with
security has resulted in a number of disasters :P

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter wrote:
> On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
>> KaiGai,
>>
>> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>>> I began to describe the list of abstraction layer functions (but not completed yet):
>>> http://wiki.postgresql.org/wiki/SEPostgreSQL_Abstraction
>> I'm not really a huge fan of 'security_' as a prefix for these
>> functions, but I don't have a better suggestion right now.
>
> Just generally, "access control" is a great way to describe what's
> actually happening here. That people conflate access control with
> security has resulted in a number of disasters :P

My concern is "access_control_" is a bit long for prefixes,
but "ac_" is too short to represent what it is doing.

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

* KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
> David Fetter wrote:
> > On Mon, Aug 03, 2009 at 11:18:55PM -0400, Stephen Frost wrote:
> > Just generally, "access control" is a great way to describe what's
> > actually happening here. That people conflate access control with
> > security has resulted in a number of disasters :P
>
> My concern is "access_control_" is a bit long for prefixes,
> but "ac_" is too short to represent what it is doing.

pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we
use in a number of other places, and has 'ac' in it..

Stephen

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>> My concern is "access_control_" is a bit long for prefixes,
>> but "ac_" is too short to represent what it is doing.

> pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we
> use in a number of other places, and has 'ac' in it..

I don't see anything wrong with "ac_". Short is good, and there isn't
any other concept in the PG internals that it would conflict with.
If there were, "pg_ac_" would surely not help to disambiguate.

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
> >> My concern is "access_control_" is a bit long for prefixes,
> >> but "ac_" is too short to represent what it is doing.
>
> > pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we
> > use in a number of other places, and has 'ac' in it..
>
> I don't see anything wrong with "ac_". Short is good, and there isn't
> any other concept in the PG internals that it would conflict with.
> If there were, "pg_ac_" would surely not help to disambiguate.

Works for me.

Thanks,

Stephen

Stephen Frost wrote:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>>> * KaiGai Kohei (kaigai(at)ak(dot)jp(dot)nec(dot)com) wrote:
>>>> My concern is "access_control_" is a bit long for prefixes,
>>>> but "ac_" is too short to represent what it is doing.
>>> pg_ac_? Still shorter than 'security_', uses the pg_ prefix, which we
>>> use in a number of other places, and has 'ac' in it..
>> I don't see anything wrong with "ac_". Short is good, and there isn't
>> any other concept in the PG internals that it would conflict with.
>> If there were, "pg_ac_" would surely not help to disambiguate.
>
> Works for me.

OK, I'll go on with the "ac_" prefix.

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