[RFC] SELinux and PostgreSQL

[RFC] SELinux and PostgreSQL

[KaiGai Kohei]

Hello,

In recent days, I'm making a plan to enhance PostgreSQL with SELinux,
and the followings are simple description about the plan currently
I have.
Any comments are so welcome. I want to revise the original design
and security model before starting implementation.

I hope to release it within next one year, if possible. :)

* The basic idea
The core facility of what I plan to enhance is an additional access
control between the client of PostgreSQL and tables, columns, rows.
(In future, the access control on binary large object(BLOB) is desirable.)

For the purpose, those database objects (table, column, row) must
have capability to hold its security context. The security context
of table and column can be stored in system catalog (pg_class and
pg_attribute), and row's one will be stored in the row generated
implicitlly.
The security context of PostgreSQL client will be obtained via
getpeercon().

I propose a new object class named as 'database' which contains the
following access vectors.

  class database
  {
      createtbl
      altertbl
      droptbl
      select
      update
      insert
      delete
      relabelfrom
      relabelto
  }

I propose some SQL functions reflecting to libselinux functions
like avc_has_perm(), getpeercon() and so on. We can use them not
only from SQL explicitly, but also implicitly appended to mask
the result set.
For example, the statement (B) will be actually executed when the
server received the statement (A).

(A) select * from customer;

(B) select * from customer where avc_has_perm(getpeercon(),
                                              security_context,
                                              DATABASE__SELECT);

* The expected behavior

When we try to create a new table, the client must have 'createtbl'
permission to the PostgreSQL server process. Then the created table
inherits the security context of the server process.
When we try to alter/drop a existing table, the client must have
'altertbl' or 'droptbl' permission to the targeted table.
If the client didn't have suitable permissions, the transaction is
aborted.

When we try to query with select statement, the client must have
'select' permission to all of the targeted table and column.
And any rows on which the client didn'n have permission is eliminated
from the result set.

When we try to query with insert statement, the client must have
'insert' permission to the targeted table and column. And any new
rows are attached a new security context given by security_compute_create()
with the client's context and the table's one.

When we try to query with update/delete, the client must have 'update'
or 'delete' permission to the target table and column. And any rows on
which the client didn't have permission is eliminated from the targets
to update or delete.
In addition, when we try to update the column contains security context,
'relabelfrom' and 'relabelto' are also evaluated.

* An example

+-------------------------------------------------------------------------+
| TABLE: customer                                                         |
+-------------------------------+-----+-----------+--------------+--------+
|        security_context       | id  | name      |  address     | income |
+-------------------------------+-----+-----------+--------------+--------+
|system_u:object_r:pgrow_t:s0   | 100 | Onodera   | Hokkaido ... | 2000   |
|system_u:object_r:pgrow_t:s0   | 101 | Hayashi   | Tokyo ...    | 2200   |
|system_u:object_r:pgrow_t:s0:c0| 102 | Meguro    | Yokohama ... | 1800   |
|system_u:object_r:pgrow_t:s0:c0| 103 | Terada    | Aomori ...   | 2100   |
|system_u:object_r:pgrow_t:s0   | 104 | Motohashi | Kyoto ...    | 2500   |
+-------------------------------+-----+-----------+--------------+--------+
| [security contexts]                                                     |
| table:  customer                  = system_u:object_r:postgresql_t:s0   |
| column: customer.security_context = system_u:object_r:postgresql_t:s0   |
| column: customer.id               = system_u:object_r:postgresql_t:s0   |
| column: customer.name             = system_u:object_r:postgresql_t:s0   |
| column: customer.mail             = system_u:object_r:postgresql_t:s0   |
| column: customer.income           = system_u:object_r:postgresql_t:s0.c1|
+-------------------------------------------------------------------------+
'income' is marked as different category, because it is a sensitive
information in this case, and it's configured non-privileged client
cannot access to some rows.

If the client context is user_u:system_r:unconfined_t:s0,
an SQL statement of "select * from customer" will return the following
result set.
+-----+-----------+--------------+
| id  | name      | address      |
+-----+-----------+--------------+
| 100 | Onodera   | Hokkaido ... |
| 101 | Hayashi   | Tokyo ...    |
| 104 | Motohashi | Kyoto ...    |
+-----+-----------+--------------+

If the client context is user_u:system_r:unconfined_t:SystemLow-SystemHigh,
the same SQL statement will return the following result set.
+-----+-----------+--------------+--------+
| id  | name      |  address     | income |
+-----+-----------+--------------+--------+
| 100 | Onodera   | Hokkaido ... | 2000   |
| 101 | Hayashi   | Tokyo ...    | 2200   |
| 102 | Meguro    | Yokohama ... | 1800   |
| 103 | Terada    | Aomori ...   | 2100   |
| 104 | Motohashi | Kyoto ...    | 2500   |
+-----+-----------+--------------+--------+

(*) '*' is not extract into 'security_context' and the column on which
    the client didn't have a permission.

Thanks for reading the long description.
Any comments are welcome for me.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


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

Re: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

On Thu, 2006-09-07 at 18:49 +0900, KaiGai Kohei wrote:
> Hello,
> 
> In recent days, I'm making a plan to enhance PostgreSQL with SELinux,
> and the followings are simple description about the plan currently
> I have.
> Any comments are so welcome. I want to revise the original design
> and security model before starting implementation.
> 
> I hope to release it within next one year, if possible. :)
> 
> * The basic idea
> The core facility of what I plan to enhance is an additional access
> control between the client of PostgreSQL and tables, columns, rows.
> (In future, the access control on binary large object(BLOB) is desirable.)
> 
> For the purpose, those database objects (table, column, row) must
> have capability to hold its security context. The security context
> of table and column can be stored in system catalog (pg_class and
> pg_attribute), and row's one will be stored in the row generated
> implicitlly.
> The security context of PostgreSQL client will be obtained via
> getpeercon().
> 
> I propose a new object class named as 'database' which contains the
> following access vectors.
> 
>   class database
>   {
>       createtbl
>       altertbl
>       droptbl
>       select
>       update
>       insert
>       delete
>       relabelfrom
>       relabelto
>   }
> 

I think you are almost there, below you talk about labeling the tables,
rows, etc individually but your object model above isn't treating them
any differently. 

The object model should have an object class for each distinct kind of
object, for example database should have create, drop, createtable,
droptable, relabelto, relabelfrom. the table object class should have
insert. update, delete, select, drop, create, etc. field (or column)
object class should have select, update, etc.

> I propose some SQL functions reflecting to libselinux functions
> like avc_has_perm(), getpeercon() and so on. We can use them not
> only from SQL explicitly, but also implicitly appended to mask
> the result set.
> For example, the statement (B) will be actually executed when the
> server received the statement (A).
> 
> (A) select * from customer;
> 
> (B) select * from customer where avc_has_perm(getpeercon(),
>                                               security_context,
>                                               DATABASE__SELECT);
> 

So is this done from within the database or are you trying to make a
trusted proxy that will munge requests before they make it to the
database server?

> * The expected behavior
> 
> When we try to create a new table, the client must have 'createtbl'
> permission to the PostgreSQL server process. Then the created table
> inherits the security context of the server process.

you mean client process right? any new object should be labeled via
policy labeling rules (eg., type_trans) from the client context.

> When we try to alter/drop a existing table, the client must have
> 'altertbl' or 'droptbl' permission to the targeted table.
> If the client didn't have suitable permissions, the transaction is
> aborted.
> 
> When we try to query with select statement, the client must have
> 'select' permission to all of the targeted table and column.
> And any rows on which the client didn'n have permission is eliminated
> from the result set.
> 
> When we try to query with insert statement, the client must have
> 'insert' permission to the targeted table and column. And any new
> rows are attached a new security context given by security_compute_create()
> with the client's context and the table's one.
> 
> When we try to query with update/delete, the client must have 'update'
> or 'delete' permission to the target table and column. And any rows on
> which the client didn't have permission is eliminated from the targets
> to update or delete.
> In addition, when we try to update the column contains security context,
> 'relabelfrom' and 'relabelto' are also evaluated.
> 
> * An example
> 
> +-------------------------------------------------------------------------+
> | TABLE: customer                                                         |
> +-------------------------------+-----+-----------+--------------+--------+
> |        security_context       | id  | name      |  address     | income |
> +-------------------------------+-----+-----------+--------------+--------+
> |system_u:object_r:pgrow_t:s0   | 100 | Onodera   | Hokkaido ... | 2000   |
> |system_u:object_r:pgrow_t:s0   | 101 | Hayashi   | Tokyo ...    | 2200   |
> |system_u:object_r:pgrow_t:s0:c0| 102 | Meguro    | Yokohama ... | 1800   |
> |system_u:object_r:pgrow_t:s0:c0| 103 | Terada    | Aomori ...   | 2100   |
> |system_u:object_r:pgrow_t:s0   | 104 | Motohashi | Kyoto ...    | 2500   |
> +-------------------------------+-----+-----------+--------------+--------+
> | [security contexts]                                                     |
> | table:  customer                  = system_u:object_r:postgresql_t:s0   |
> | column: customer.security_context = system_u:object_r:postgresql_t:s0   |
> | column: customer.id               = system_u:object_r:postgresql_t:s0   |
> | column: customer.name             = system_u:object_r:postgresql_t:s0   |
> | column: customer.mail             = system_u:object_r:postgresql_t:s0   |
> | column: customer.income           = system_u:object_r:postgresql_t:s0.c1|
> +-------------------------------------------------------------------------+
> 'income' is marked as different category, because it is a sensitive
> information in this case, and it's configured non-privileged client
> cannot access to some rows.
> 
> If the client context is user_u:system_r:unconfined_t:s0,
> an SQL statement of "select * from customer" will return the following
> result set.
> +-----+-----------+--------------+
> | id  | name      | address      |
> +-----+-----------+--------------+
> | 100 | Onodera   | Hokkaido ... |
> | 101 | Hayashi   | Tokyo ...    |
> | 104 | Motohashi | Kyoto ...    |
> +-----+-----------+--------------+
> 
> If the client context is user_u:system_r:unconfined_t:SystemLow-SystemHigh,
> the same SQL statement will return the following result set.
> +-----+-----------+--------------+--------+
> | id  | name      |  address     | income |
> +-----+-----------+--------------+--------+
> | 100 | Onodera   | Hokkaido ... | 2000   |
> | 101 | Hayashi   | Tokyo ...    | 2200   |
> | 102 | Meguro    | Yokohama ... | 1800   |
> | 103 | Terada    | Aomori ...   | 2100   |
> | 104 | Motohashi | Kyoto ...    | 2500   |
> +-----+-----------+--------------+--------+
> 
> (*) '*' is not extract into 'security_context' and the column on which
>     the client didn't have a permission.
> 
> Thanks for reading the long description.
> Any comments are welcome for me.


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

Re: [RFC] SELinux and PostgreSQL

[Russell Coker]

On Thursday 07 September 2006 22:52, Joshua Brindle <jbrindle@tresys.com> 
wrote:
> > I propose a new object class named as 'database' which contains the
> > following access vectors.
> >
> >   class database
> >   {
> >       createtbl
> >       altertbl
> >       droptbl
> >       select
> >       update
> >       insert
> >       delete
> >       relabelfrom
> >       relabelto
> >   }
>
> I think you are almost there, below you talk about labeling the tables,
> rows, etc individually but your object model above isn't treating them
> any differently.
>
> The object model should have an object class for each distinct kind of
> object, for example database should have create, drop, createtable,
> droptable, relabelto, relabelfrom. the table object class should have
> insert. update, delete, select, drop, create, etc. field (or column)
> object class should have select, update, etc.

Do we need separate object classes for database and table?

We can consider databases and tables to be both roughly equivalent to 
directories in the filesystem permissions.  In a Reiser4 model that would 
be /database/table/row.  ;)

So we could have:
table_auto_trans(dba1_t, system_db_t, database1_t, table)
table_auto_trans(dba1_t, database1_t, table1_t, table)
table_trans(dba1_t, database1_t, { table2_t table3_t }, table)
table_auto_trans({ dba1_t db_user1_t }, table2_t, row1_t, row)

> > (A) select * from customer;
> >
> > (B) select * from customer where avc_has_perm(getpeercon(),
> >                                               security_context,
> >                                               DATABASE__SELECT);
>
> So is this done from within the database or are you trying to make a
> trusted proxy that will munge requests before they make it to the
> database server?

When I briefly discussed such things with KaiGai the idea was to have it 
within the database.  A proxy would be very inefficient for this if SE Linux 
controls were used in any serious manner.  Large amounts of data could be 
retrieved only to be discarded by the proxy.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

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

Re: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

On Thu, 2006-09-07 at 23:24 +1000, Russell Coker wrote:
> On Thursday 07 September 2006 22:52, Joshua Brindle <jbrindle@tresys.com> 
> wrote:
> > > I propose a new object class named as 'database' which contains the
> > > following access vectors.
> > >
> > >   class database
> > >   {
> > >       createtbl
> > >       altertbl
> > >       droptbl
> > >       select
> > >       update
> > >       insert
> > >       delete
> > >       relabelfrom
> > >       relabelto
> > >   }
> >
> > I think you are almost there, below you talk about labeling the tables,
> > rows, etc individually but your object model above isn't treating them
> > any differently.
> >
> > The object model should have an object class for each distinct kind of
> > object, for example database should have create, drop, createtable,
> > droptable, relabelto, relabelfrom. the table object class should have
> > insert. update, delete, select, drop, create, etc. field (or column)
> > object class should have select, update, etc.
> 
> Do we need separate object classes for database and table?
> 
> We can consider databases and tables to be both roughly equivalent to 
> directories in the filesystem permissions.  In a Reiser4 model that would 
> be /database/table/row.  ;)
> 

databases and tables are different. You can select on a table, you
cannot select on a database. you can insert into a table, you cannot
insert into a database, and so on.

> So we could have:
> table_auto_trans(dba1_t, system_db_t, database1_t, table)
> table_auto_trans(dba1_t, database1_t, table1_t, table)
> table_trans(dba1_t, database1_t, { table2_t table3_t }, table)
> table_auto_trans({ dba1_t db_user1_t }, table2_t, row1_t, row)
> 
> > > (A) select * from customer;
> > >
> > > (B) select * from customer where avc_has_perm(getpeercon(),
> > >                                               security_context,
> > >                                               DATABASE__SELECT);
> >
> > So is this done from within the database or are you trying to make a
> > trusted proxy that will munge requests before they make it to the
> > database server?
> 
> When I briefly discussed such things with KaiGai the idea was to have it 
> within the database.  A proxy would be very inefficient for this if SE Linux 
> controls were used in any serious manner.  Large amounts of data could be 
> retrieved only to be discarded by the proxy.
> 
 
Not really. The proxy would change the query as above (A and B) and the
database server would only return the results that match the query
(including the avc_has_perm) and the proxy will pass the results on. The
proxy in this model manipulates the query, not the result set.

One could even use the proxy model within the same process space to
manipulate the query as it enters the database server instead of hooking
in to the database server at every access point.

The bad part about this is that it makes for a less fine grained model
than hooking at access points. 

One thing to think about is stored procedures and how those can be dealt
with, triggers, etc. Without access control hooks triggers are much
harder to deal with access control wise, as are stored procedures.


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

Re: [RFC] SELinux and PostgreSQL

[Russell Coker]

On Thursday 07 September 2006 23:54, Joshua Brindle <jbrindle@tresys.com> 
wrote:
> > Do we need separate object classes for database and table?
> >
> > We can consider databases and tables to be both roughly equivalent to
> > directories in the filesystem permissions.  In a Reiser4 model that would
> > be /database/table/row.  ;)
>
> databases and tables are different. You can select on a table, you
> cannot select on a database. you can insert into a table, you cannot
> insert into a database, and so on.

Files, directories, and symbolic links are different.  You can swapon to a 
file but not a directory or a sym-link.  You can't mounton a sym-link.  
Currently the object classes defined in the SE Linux policy support such 
things.

> > > So is this done from within the database or are you trying to make a
> > > trusted proxy that will munge requests before they make it to the
> > > database server?
> >
> > When I briefly discussed such things with KaiGai the idea was to have it
> > within the database.  A proxy would be very inefficient for this if SE
> > Linux controls were used in any serious manner.  Large amounts of data
> > could be retrieved only to be discarded by the proxy.
>
> Not really. The proxy would change the query as above (A and B) and the
> database server would only return the results that match the query
> (including the avc_has_perm) and the proxy will pass the results on. The
> proxy in this model manipulates the query, not the result set.

To implement the functionality of having a SELECT return only rows that you 
are permitted to see the result set will be changed.  Think of a situation 
where you have 100 user domains permitted to access a table and 100 types of 
row.  The administrator would see all rows, but each user would only see a 
small fraction of them.

Then when you do a join of two tables with such configurations things would 
get even more interesting for the author of a proxy.

> One could even use the proxy model within the same process space to
> manipulate the query as it enters the database server instead of hooking
> in to the database server at every access point.
>
> The bad part about this is that it makes for a less fine grained model
> than hooking at access points.

If you want to only control table access then things become much easier.

> One thing to think about is stored procedures and how those can be dealt
> with, triggers, etc. Without access control hooks triggers are much
> harder to deal with access control wise, as are stored procedures.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

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

Re: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

On Fri, 2006-09-08 at 00:07 +1000, Russell Coker wrote:
> On Thursday 07 September 2006 23:54, Joshua Brindle <jbrindle@tresys.com> 
> wrote:
> > > Do we need separate object classes for database and table?
> > >
> > > We can consider databases and tables to be both roughly equivalent to
> > > directories in the filesystem permissions.  In a Reiser4 model that would
> > > be /database/table/row.  ;)
> >
> > databases and tables are different. You can select on a table, you
> > cannot select on a database. you can insert into a table, you cannot
> > insert into a database, and so on.
> 
> Files, directories, and symbolic links are different.  You can swapon to a 
> file but not a directory or a sym-link.  You can't mounton a sym-link.  
> Currently the object classes defined in the SE Linux policy support such 
> things.
> 

seems like you are agreeing. file, sym_file and dir are all different
object classes, as should be databases and tables.

> > > > So is this done from within the database or are you trying to make a
> > > > trusted proxy that will munge requests before they make it to the
> > > > database server?
> > >
> > > When I briefly discussed such things with KaiGai the idea was to have it
> > > within the database.  A proxy would be very inefficient for this if SE
> > > Linux controls were used in any serious manner.  Large amounts of data
> > > could be retrieved only to be discarded by the proxy.
> >
> > Not really. The proxy would change the query as above (A and B) and the
> > database server would only return the results that match the query
> > (including the avc_has_perm) and the proxy will pass the results on. The
> > proxy in this model manipulates the query, not the result set.
> 
> To implement the functionality of having a SELECT return only rows that you 
> are permitted to see the result set will be changed.  Think of a situation 
> where you have 100 user domains permitted to access a table and 100 types of 
> row.  The administrator would see all rows, but each user would only see a 
> small fraction of them.
> 

No, you do exactly what KaiGai said above:

> > (A) select * from customer;
> >
> > (B) select * from customer where avc_has_perm(getpeercon(),
> >                                               security_context,
> >                                               DATABASE__SELECT);
>

A turns in to B via the proxy. Then the database does the avc_has_perm
check as part of the query. An administrator would have more access via
the policy. The proxy would not be discarding anything.


> Then when you do a join of two tables with such configurations things would 
> get even more interesting for the author of a proxy.
> 
> > One could even use the proxy model within the same process space to
> > manipulate the query as it enters the database server instead of hooking
> > in to the database server at every access point.
> >
> > The bad part about this is that it makes for a less fine grained model
> > than hooking at access points.
> 
> If you want to only control table access then things become much easier.
> 

like I said, "it makes for a less fine grained model"

> > One thing to think about is stored procedures and how those can be dealt
> > with, triggers, etc. Without access control hooks triggers are much
> > harder to deal with access control wise, as are stored procedures.
> 


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

Re: [RFC] SELinux and PostgreSQL

[KaiGai Kohei]

I intend to filter the result set by appending avc_has_perm(...) condition
for each targeted table. I believe it is the most simple implementation
and it can utilize the optimizer of PostgreSQL.

>>> (A) select * from customer;
>>>
>>> (B) select * from customer where avc_has_perm(getpeercon(),
>>>                                               security_context,
>>>                                               DATABASE__SELECT);
> 
> A turns in to B via the proxy. Then the database does the avc_has_perm
> check as part of the query. An administrator would have more access via
> the policy. The proxy would not be discarding anything.

If we consider the modules in PostgreSQL as separated processes,
we may be able to say this mechanism the proxy.
But we cannot rewrite SQL statement outside the server process,
because PosgreSQL itself may rewrite the query tree internally.

The details are described in the following URL:
  Chapter 34. The Rule System
  http://www.postgresql.org/docs/8.1/static/rules.html

By the above reason, we must inject additional conditions of
SELinux after completion of query rewriting, and we cannot
have any option except the implementation within DBMS.

>> Then when you do a join of two tables with such configurations things would 
>> get even more interesting for the author of a proxy.
>>
>>> One could even use the proxy model within the same process space to
>>> manipulate the query as it enters the database server instead of hooking
>>> in to the database server at every access point.
>>>
>>> The bad part about this is that it makes for a less fine grained model
>>> than hooking at access points.
>> If you want to only control table access then things become much easier.

When we do a join of two tables, the joined virtual table are generated
from filtered two result set. All of its contains are allowed to select.

The result is same, even if a view was defined as a select statement
which do a join of multiple tables.

> like I said, "it makes for a less fine grained model"
> 
>>> One thing to think about is stored procedures and how those can be dealt
>>> with, triggers, etc. Without access control hooks triggers are much
>>> harder to deal with access control wise, as are stored procedures.

The stored procedure is a bit considerable.
Now I cannot conclude about its handling whether it's suitable for this solution.
More hacking to PostgreSQL is necessary. ;)

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL

[KaiGai Kohei]

Sorry for delayed replying. :)

Russell Coker wrote:
> On Thursday 07 September 2006 22:52, Joshua Brindle <jbrindle@tresys.com> 
> wrote:
>>> I propose a new object class named as 'database' which contains the
>>> following access vectors.
>>>
>>>   class database
>>>   {
>>>       createtbl
>>>       altertbl
>>>       droptbl
>>>       select
>>>       update
>>>       insert
>>>       delete
>>>       relabelfrom
>>>       relabelto
>>>   }
>> I think you are almost there, below you talk about labeling the tables,
>> rows, etc individually but your object model above isn't treating them
>> any differently.
>>
>> The object model should have an object class for each distinct kind of
>> object, for example database should have create, drop, createtable,
>> droptable, relabelto, relabelfrom. the table object class should have
>> insert. update, delete, select, drop, create, etc. field (or column)
>> object class should have select, update, etc.
> 
> Do we need separate object classes for database and table?
> 
> We can consider databases and tables to be both roughly equivalent to 
> directories in the filesystem permissions.  In a Reiser4 model that would 
> be /database/table/row.  ;)
> 
> So we could have:
> table_auto_trans(dba1_t, system_db_t, database1_t, table)
> table_auto_trans(dba1_t, database1_t, table1_t, table)
> table_trans(dba1_t, database1_t, { table2_t table3_t }, table)
> table_auto_trans({ dba1_t db_user1_t }, table2_t, row1_t, row)

I agree Russell's suggestion, because we can describe those structure
with separated type and type_trans rule.
In addition, it will be more easily applicable to another DBMS.

I have a question to Russell.
How is the security context of database attached?
I estimate it should be done by type_trans rule with server process context
and clients process's context on database object class.

>>> (A) select * from customer;
>>>
>>> (B) select * from customer where avc_has_perm(getpeercon(),
>>>                                               security_context,
>>>                                               DATABASE__SELECT);
>> So is this done from within the database or are you trying to make a
>> trusted proxy that will munge requests before they make it to the
>> database server?
> 
> When I briefly discussed such things with KaiGai the idea was to have it 
> within the database.  A proxy would be very inefficient for this if SE Linux 
> controls were used in any serious manner.  Large amounts of data could be 
> retrieved only to be discarded by the proxy.

I intend to implement it as a patch against to PostgreSQL, not a independent
proxy server.
The reason of this decision is that we cannot enforce SELinux's access controls
to any tables, columns and rows, even if the proxy server rewrite SQL statement.
A query to view is a representative example.
PostgreSQL often rewrite SQL statement into something completely different.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

KaiGai Kohei wrote:
> Sorry for delayed replying. :)
> 
> Russell Coker wrote:
>> On Thursday 07 September 2006 22:52, Joshua Brindle 
>> <jbrindle@tresys.com> wrote:
>>>> I propose a new object class named as 'database' which contains the
>>>> following access vectors.
>>>>
>>>>   class database
>>>>   {
>>>>       createtbl
>>>>       altertbl
>>>>       droptbl
>>>>       select
>>>>       update
>>>>       insert
>>>>       delete
>>>>       relabelfrom
>>>>       relabelto
>>>>   }
>>> I think you are almost there, below you talk about labeling the tables,
>>> rows, etc individually but your object model above isn't treating them
>>> any differently.
>>>
>>> The object model should have an object class for each distinct kind of
>>> object, for example database should have create, drop, createtable,
>>> droptable, relabelto, relabelfrom. the table object class should have
>>> insert. update, delete, select, drop, create, etc. field (or column)
>>> object class should have select, update, etc.
>>
>> Do we need separate object classes for database and table?
>>
>> We can consider databases and tables to be both roughly equivalent to 
>> directories in the filesystem permissions.  In a Reiser4 model that 
>> would be /database/table/row.  ;)
>>
>> So we could have:
>> table_auto_trans(dba1_t, system_db_t, database1_t, table)
>> table_auto_trans(dba1_t, database1_t, table1_t, table)
>> table_trans(dba1_t, database1_t, { table2_t table3_t }, table)
>> table_auto_trans({ dba1_t db_user1_t }, table2_t, row1_t, row)
> 
> I agree Russell's suggestion, because we can describe those structure
> with separated type and type_trans rule.
> In addition, it will be more easily applicable to another DBMS.
> 

under flask object classes are used to differentiate kinds of objects. 
It will make the database access control much more fine grained if you 
implement a proper object model.

> I have a question to Russell.
> How is the security context of database attached?
> I estimate it should be done by type_trans rule with server process context
> and clients process's context on database object class.
> 

you shouldn't use the server process context since the objects are being 
created by the client ultimately and should be labeled based on the 
label of the client. Labeling based on the server context would make for 
almost unusable labeling granularity.

>>>> (A) select * from customer;
>>>>
>>>> (B) select * from customer where avc_has_perm(getpeercon(),
>>>>                                               security_context,
>>>>                                               DATABASE__SELECT);
>>> So is this done from within the database or are you trying to make a
>>> trusted proxy that will munge requests before they make it to the
>>> database server?
>>
>> When I briefly discussed such things with KaiGai the idea was to have 
>> it within the database.  A proxy would be very inefficient for this if 
>> SE Linux controls were used in any serious manner.  Large amounts of 
>> data could be retrieved only to be discarded by the proxy.
> 
> I intend to implement it as a patch against to PostgreSQL, not a 
> independent
> proxy server.
> The reason of this decision is that we cannot enforce SELinux's access 
> controls
> to any tables, columns and rows, even if the proxy server rewrite SQL 
> statement.
> A query to view is a representative example.
> PostgreSQL often rewrite SQL statement into something completely different.
> 
> Thanks,

Proxy didn't necessarily mean a proxy server, it could mean anything 
(even in the same process space) that just relayed and changed the query 
rather than adding access control callbacks at access points in the 
database, it is 2 different models of implementing access control and it 
sounds like you want do to the proxy rather than the hooks.

I still think triggers and stored procedures can be problematic with 
this model, just keep it in mind..

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

Re: [RFC] SELinux and PostgreSQL

[KaiGai Kohei]

>>> Do we need separate object classes for database and table?
>>>
>>> We can consider databases and tables to be both roughly equivalent to 
>>> directories in the filesystem permissions.  In a Reiser4 model that 
>>> would be /database/table/row.  ;)
>>>
>>> So we could have:
>>> table_auto_trans(dba1_t, system_db_t, database1_t, table)
>>> table_auto_trans(dba1_t, database1_t, table1_t, table)
>>> table_trans(dba1_t, database1_t, { table2_t table3_t }, table)
>>> table_auto_trans({ dba1_t db_user1_t }, table2_t, row1_t, row)
>>
>> I agree Russell's suggestion, because we can describe those structure
>> with separated type and type_trans rule.
>> In addition, it will be more easily applicable to another DBMS.
>>
> 
> under flask object classes are used to differentiate kinds of objects. 
> It will make the database access control much more fine grained if you 
> implement a proper object model.

Umm, I felt both opinions are correct.
I want to consider for a while and hear any more opinions.

>> I have a question to Russell.
>> How is the security context of database attached?
>> I estimate it should be done by type_trans rule with server process 
>> context
>> and clients process's context on database object class.
>>
> 
> you shouldn't use the server process context since the objects are being 
> created by the client ultimately and should be labeled based on the 
> label of the client. Labeling based on the server context would make for 
> almost unusable labeling granularity.

I'm sorry if my description is confusable.
I didn't say we should use server process's security context as a initial
label of the database. The result of security_compute_create() is used
as a initial label of the database, and the arguments of it is client
process's context as a subject and server process's context as a object.
Do you think it's a strange design?

>> I intend to implement it as a patch against to PostgreSQL, not a 
>> independent
>> proxy server.
>> The reason of this decision is that we cannot enforce SELinux's access 
>> controls
>> to any tables, columns and rows, even if the proxy server rewrite SQL 
>> statement.
>> A query to view is a representative example.
>> PostgreSQL often rewrite SQL statement into something completely 
>> different.
>>
>> Thanks,
> 
> Proxy didn't necessarily mean a proxy server, it could mean anything 
> (even in the same process space) that just relayed and changed the query 
> rather than adding access control callbacks at access points in the 
> database, it is 2 different models of implementing access control and it 
> sounds like you want do to the proxy rather than the hooks.

Ah, OK. I have misunderstood what you say.
In the plan currently I have, the 'proxy' is deployed between the rewriter
and the optimizer.
(*) the rewriter and the optimizer are modules in PostgreSQL.

> I still think triggers and stored procedures can be problematic with 
> this model, just keep it in mind..

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

On Fri, 2006-09-08 at 00:52 +0900, KaiGai Kohei wrote:
> >>> Do we need separate object classes for database and table?
> >>>
> >>> We can consider databases and tables to be both roughly equivalent to 
> >>> directories in the filesystem permissions.  In a Reiser4 model that 
> >>> would be /database/table/row.  ;)
> >>>
> >>> So we could have:
> >>> table_auto_trans(dba1_t, system_db_t, database1_t, table)
> >>> table_auto_trans(dba1_t, database1_t, table1_t, table)
> >>> table_trans(dba1_t, database1_t, { table2_t table3_t }, table)
> >>> table_auto_trans({ dba1_t db_user1_t }, table2_t, row1_t, row)
> >>
> >> I agree Russell's suggestion, because we can describe those structure
> >> with separated type and type_trans rule.
> >> In addition, it will be more easily applicable to another DBMS.
> >>
> > 
> > under flask object classes are used to differentiate kinds of objects. 
> > It will make the database access control much more fine grained if you 
> > implement a proper object model.
> 
> Umm, I felt both opinions are correct.
> I want to consider for a while and hear any more opinions.
> 

we've been thinking about this a little here at tresys and have some
ideas about the object model if you are interested..

> >> I have a question to Russell.
> >> How is the security context of database attached?
> >> I estimate it should be done by type_trans rule with server process 
> >> context
> >> and clients process's context on database object class.
> >>
> > 
> > you shouldn't use the server process context since the objects are being 
> > created by the client ultimately and should be labeled based on the 
> > label of the client. Labeling based on the server context would make for 
> > almost unusable labeling granularity.
> 
> I'm sorry if my description is confusable.
> I didn't say we should use server process's security context as a initial
> label of the database. The result of security_compute_create() is used
> as a initial label of the database, and the arguments of it is client
> process's context as a subject and server process's context as a object.
> Do you think it's a strange design?
> 

The database, table and column objects should be labeled the same way
any other object in SELinux is labeled. It can either be a policy driven
label (security_compute_create) or be explicit. When an administrator
sets up the schema for a table he'll want to label the columns
explicitly if they'll have different access matrices. SQL extensions
will be required to handle this:

CREATE table users ( username char(24), password char(24) 
context('system_u:object_r:db_users_password_t'));

(or whatever)

meaning that parts of the schema have labels (which is how you determine
if one can insert, delete, etc into a specific table). Additionally any
data put into the database is labeled via security_compute_create on a
per row basis (if you choose to make it that fine grained). 

At a minimum you should have the different kinds of objects (databases,
tables, columns, stored procedures) and label them either explicitly or
via security_compute_create.

> >> I intend to implement it as a patch against to PostgreSQL, not a 
> >> independent
> >> proxy server.
> >> The reason of this decision is that we cannot enforce SELinux's access 
> >> controls
> >> to any tables, columns and rows, even if the proxy server rewrite SQL 
> >> statement.
> >> A query to view is a representative example.
> >> PostgreSQL often rewrite SQL statement into something completely 
> >> different.
> >>
> >> Thanks,
> > 
> > Proxy didn't necessarily mean a proxy server, it could mean anything 
> > (even in the same process space) that just relayed and changed the query 
> > rather than adding access control callbacks at access points in the 
> > database, it is 2 different models of implementing access control and it 
> > sounds like you want do to the proxy rather than the hooks.
> 
> Ah, OK. I have misunderstood what you say.
> In the plan currently I have, the 'proxy' is deployed between the rewriter
> and the optimizer.
> (*) the rewriter and the optimizer are modules in PostgreSQL.
> 
> > I still think triggers and stored procedures can be problematic with 
> > this model, just keep it in mind..
> 

Reiterating above, I don't think you can get full coverage of either the
schema model above or fine grained row level access with the proxy model
above.


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

Re: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

On Thu, 2006-09-07 at 13:02 -0400, Joshua Brindle wrote:
> On Fri, 2006-09-08 at 00:52 +0900, KaiGai Kohei wrote:
> > >>> Do we need separate object classes for database and table?
> > >>>
> > >>> We can consider databases and tables to be both roughly equivalent to 
> > >>> directories in the filesystem permissions.  In a Reiser4 model that 
> > >>> would be /database/table/row.  ;)
> > >>>
> > >>> So we could have:
> > >>> table_auto_trans(dba1_t, system_db_t, database1_t, table)
> > >>> table_auto_trans(dba1_t, database1_t, table1_t, table)
> > >>> table_trans(dba1_t, database1_t, { table2_t table3_t }, table)
> > >>> table_auto_trans({ dba1_t db_user1_t }, table2_t, row1_t, row)
> > >>
> > >> I agree Russell's suggestion, because we can describe those structure
> > >> with separated type and type_trans rule.
> > >> In addition, it will be more easily applicable to another DBMS.
> > >>
> > > 
> > > under flask object classes are used to differentiate kinds of objects. 
> > > It will make the database access control much more fine grained if you 
> > > implement a proper object model.
> > 
> > Umm, I felt both opinions are correct.
> > I want to consider for a while and hear any more opinions.
> > 
> 
> we've been thinking about this a little here at tresys and have some
> ideas about the object model if you are interested..
> 
> > >> I have a question to Russell.
> > >> How is the security context of database attached?
> > >> I estimate it should be done by type_trans rule with server process 
> > >> context
> > >> and clients process's context on database object class.
> > >>
> > > 
> > > you shouldn't use the server process context since the objects are being 
> > > created by the client ultimately and should be labeled based on the 
> > > label of the client. Labeling based on the server context would make for 
> > > almost unusable labeling granularity.
> > 
> > I'm sorry if my description is confusable.
> > I didn't say we should use server process's security context as a initial
> > label of the database. The result of security_compute_create() is used
> > as a initial label of the database, and the arguments of it is client
> > process's context as a subject and server process's context as a object.
> > Do you think it's a strange design?
> > 
> 
> The database, table and column objects should be labeled the same way
> any other object in SELinux is labeled. It can either be a policy driven
> label (security_compute_create) or be explicit. When an administrator
> sets up the schema for a table he'll want to label the columns
> explicitly if they'll have different access matrices. SQL extensions
> will be required to handle this:
> 
> CREATE table users ( username char(24), password char(24) 
> context('system_u:object_r:db_users_password_t'));
> 
> (or whatever)
> 
> meaning that parts of the schema have labels (which is how you determine
> if one can insert, delete, etc into a specific table). Additionally any
> data put into the database is labeled via security_compute_create on a
> per row basis (if you choose to make it that fine grained). 
> 
> At a minimum you should have the different kinds of objects (databases,
> tables, columns, stored procedures) and label them either explicitly or
> via security_compute_create.

Speaking of stored procedures, Karl reminded me that we probably want
stored procedures to be entrypoints into other domains so that you can
use them as trusted info flow filters.


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

Re: [RFC] SELinux and PostgreSQL

[KaiGai Kohei]

Because the SMTP server of my office was not allowed to deliver
SELinux-list, I posted it again from my house.
I'm sorry if you received same message twice.

>> At a minimum you should have the different kinds of objects (databases,
>> tables, columns, stored procedures) and label them either explicitly or
>> via security_compute_create.
> 
> Speaking of stored procedures, Karl reminded me that we probably want
> stored procedures to be entrypoints into other domains so that you can
> use them as trusted info flow filters.

I also think it's a good idea.
This mechanism makes none-privileged users deal with sensitive data like
password safety.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL

[KaiGai Kohei]

Because the SMTP server of my office was not allowed to deliver
SELinux-list, I posted it again from my house.
I'm sorry if you received same message twice.

>>> under flask object classes are used to differentiate kinds of objects.
>>> It will make the database access control much more fine grained if you
>>> implement a proper object model.
>> Umm, I felt both opinions are correct.
>> I want to consider for a while and hear any more opinions.
>>
>
> we've been thinking about this a little here at tresys and have some
> ideas about the object model if you are interested..

I'm interested in your ideas. Can you post it?

>>> you shouldn't use the server process context since the objects are being
>>> created by the client ultimately and should be labeled based on the
>>> label of the client. Labeling based on the server context would make for
>>> almost unusable labeling granularity.
>> I'm sorry if my description is confusable.
>> I didn't say we should use server process's security context as a initial
>> label of the database. The result of security_compute_create() is used
>> as a initial label of the database, and the arguments of it is client
>> process's context as a subject and server process's context as a object.
>> Do you think it's a strange design?
>>
>
> The database, table and column objects should be labeled the same way
> any other object in SELinux is labeled. It can either be a policy driven
> label (security_compute_create) or be explicit. When an administrator
> sets up the schema for a table he'll want to label the columns
> explicitly if they'll have different access matrices. SQL extensions
> will be required to handle this:
>
> CREATE table users ( username char(24), password char(24)
> context('system_u:object_r:db_users_password_t'));
>
> (or whatever)
>
> meaning that parts of the schema have labels (which is how you determine
> if one can insert, delete, etc into a specific table). Additionally any
> data put into the database is labeled via security_compute_create on a
> per row basis (if you choose to make it that fine grained).
>
> At a minimum you should have the different kinds of objects (databases,
> tables, columns, stored procedures) and label them either explicitly or
> via security_compute_create.

I agree this opinion those objects should be labeled either
implicitly by security policy or explicitly by administrator.

As you mentioned, we can determine the initial label of rows and
tables from security_compute_create() with the combination of the
client process and the label of the table or the database.
But how can we decide the initial lebal of database in this case?

To solve this problem, I said the initial label of database should be
determine from security_compute_create() with the combination of the
client process's label and the server process's label.
In other words, I intend to use the server process's context as an
entry point of type transiton for newly created database.

>>>> I intend to implement it as a patch against to PostgreSQL, not a
>>>> independent
>>>> proxy server.
>>>> The reason of this decision is that we cannot enforce SELinux's access
>>>> controls
>>>> to any tables, columns and rows, even if the proxy server rewrite SQL
>>>> statement.
>>>> A query to view is a representative example.
>>>> PostgreSQL often rewrite SQL statement into something completely
>>>> different.
>>>>
>>>> Thanks,
>>> Proxy didn't necessarily mean a proxy server, it could mean anything
>>> (even in the same process space) that just relayed and changed the query
>>> rather than adding access control callbacks at access points in the
>>> database, it is 2 different models of implementing access control and it
>>> sounds like you want do to the proxy rather than the hooks.
>> Ah, OK. I have misunderstood what you say.
>> In the plan currently I have, the 'proxy' is deployed between the rewriter
>> and the optimizer.
>> (*) the rewriter and the optimizer are modules in PostgreSQL.
>>
>>> I still think triggers and stored procedures can be problematic with
>>> this model, just keep it in mind..
>
> Reiterating above, I don't think you can get full coverage of either the
> schema model above or fine grained row level access with the proxy model
> above.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL

[Russell Coker]

On Friday 08 September 2006 00:28, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> The reason of this decision is that we cannot enforce SELinux's access
> controls to any tables, columns and rows, even if the proxy server rewrite
> SQL statement.

You want to label columns AND rows?

How is that going to work?  I can understand the desire for this (EG have a 
password column in the user table), but the mechanism of enforcing this will 
be tricky to say the least.  Will you perform two access checks on each cell, 
one for column and one for row?

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

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

RE: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

> From: Russell Coker [mailto:russell@coker.com.au] 
> 
> On Friday 08 September 2006 00:28, KaiGai Kohei 
> <kaigai@kaigai.gr.jp> wrote:
> > The reason of this decision is that we cannot enforce 
> SELinux's access 
> > controls to any tables, columns and rows, even if the proxy server 
> > rewrite SQL statement.
> 
> You want to label columns AND rows?
> 
> How is that going to work?  I can understand the desire for 
> this (EG have a password column in the user table), but the 
> mechanism of enforcing this will be tricky to say the least.  
> Will you perform two access checks on each cell, one for 
> column and one for row?

Columns are part of the schema, rows are data, they are different
objects.

You label columns because an entire column might contain important data
(eg., a password). The rows are labeled because some domain X is putting
data in them and you still want to be able to use policy to enforce
information flow goals with the policy whether you are using kernel
objects or userspace objects. In other words, if user X is topsecret and
writes a row to a table you don't want user Y who is just secret to read
it. 

The latter can be accomplished in many ways including virtual databases
(eg., views) or by modifying queries (like KaiGai mentioned in his first
email) or filtering results or course grained labeling on tables so that
each table is only 1 context. Some are better approaches than others, I
won't go into that at this point..

The answer is yes, there may be multiple security queries per database
query, due to the data model of relational databases this is optimal and
necessary IMO. This isn't abnormal either. Creating a file, for example,
requires dir { add_name search}, file { create } and filesystem {
associate } (for the object). The policy server has similar multiple
checks in its current state. I don't think there is a problem if they
overlap some as long as one isn't necessarilly a superset of another
(which would just be redundant) which is not the case here since we are
talking about different objects that can be labeled differently for any
given query.


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

RE: [RFC] SELinux and PostgreSQL

[James W. Hoeft]

> > From: Russell Coker [mailto:russell@coker.com.au]
> >
> > On Friday 08 September 2006 00:28, KaiGai Kohei
> > <kaigai@kaigai.gr.jp> wrote:
> > > The reason of this decision is that we cannot enforce
> > SELinux's access
> > > controls to any tables, columns and rows, even if the proxy server
> > > rewrite SQL statement.
> >
> > You want to label columns AND rows?
> >
> > How is that going to work?  I can understand the desire for
> > this (EG have a password column in the user table), but the
> > mechanism of enforcing this will be tricky to say the least.
> > Will you perform two access checks on each cell, one for
> > column and one for row?
>
>Columns are part of the schema, rows are data, they are different
>objects.
>
>You label columns because an entire column might contain important data
>(eg., a password). The rows are labeled because some domain X is putting
>data in them and you still want to be able to use policy to enforce
>information flow goals with the policy whether you are using kernel
>objects or userspace objects. In other words, if user X is topsecret and
>writes a row to a table you don't want user Y who is just secret to read
>it.
>
>The latter can be accomplished in many ways including virtual databases
>(eg., views) or by modifying queries (like KaiGai mentioned in his first
>email) or filtering results or course grained labeling on tables so that
>each table is only 1 context. Some are better approaches than others, I
>won't go into that at this point..
>
>The answer is yes, there may be multiple security queries per database
>query, due to the data model of relational databases this is optimal and
>necessary IMO. This isn't abnormal either. Creating a file, for example,
>requires dir { add_name search}, file { create } and filesystem {
>associate } (for the object). The policy server has similar multiple
>checks in its current state. I don't think there is a problem if they
>overlap some as long as one isn't necessarilly a superset of another
>(which would just be redundant) which is not the case here since we are
>talking about different objects that can be labeled differently for any
>given query.

I'm confused. Password column is a good example - let's say the 
password column is labeled at top secret, then how can a secret user 
create a new row? I would assume a password would be required, but 
that either means a secret user cannot read or cannot write (or can't 
do either). If that's not the case, then does that mean the row can 
be created without a password? In which case, does that mean only top 
secret users can specify passwords? In which case, what does a 
password provide. I may be missing something here, but seems the data 
(rows) should have labels and schema (columns) should be validated 
using some other mechanism (e.g., ACL or similar). I would also think 
multiple security queries per database query would present a 
significant performance hit (but then again, that may be the price we 
have to pay for the added security).

Jim 


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

RE: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

> From: James W. Hoeft [mailto:Jim@MagitekLtd.com] 
> 
> 
> > > From: Russell Coker [mailto:russell@coker.com.au]
> > >
> > > On Friday 08 September 2006 00:28, KaiGai Kohei 
> > > <kaigai@kaigai.gr.jp> wrote:
> > > > The reason of this decision is that we cannot enforce
> > > SELinux's access
> > > > controls to any tables, columns and rows, even if the 
> proxy server 
> > > > rewrite SQL statement.
> > >
> > > You want to label columns AND rows?
> > >
> > > How is that going to work?  I can understand the desire 
> for this (EG 
> > > have a password column in the user table), but the mechanism of 
> > > enforcing this will be tricky to say the least.
> > > Will you perform two access checks on each cell, one for 
> column and 
> > > one for row?
> >
> >Columns are part of the schema, rows are data, they are different 
> >objects.
> >
> >You label columns because an entire column might contain 
> important data 
> >(eg., a password). The rows are labeled because some domain X is 
> >putting data in them and you still want to be able to use policy to 
> >enforce information flow goals with the policy whether you are using 
> >kernel objects or userspace objects. In other words, if user X is 
> >topsecret and writes a row to a table you don't want user Y 
> who is just 
> >secret to read it.
> >
> >The latter can be accomplished in many ways including 
> virtual databases 
> >(eg., views) or by modifying queries (like KaiGai mentioned in his 
> >first
> >email) or filtering results or course grained labeling on tables so 
> >that each table is only 1 context. Some are better approaches than 
> >others, I won't go into that at this point..
> >
> >The answer is yes, there may be multiple security queries 
> per database 
> >query, due to the data model of relational databases this is optimal 
> >and necessary IMO. This isn't abnormal either. Creating a file, for 
> >example, requires dir { add_name search}, file { create } and 
> >filesystem { associate } (for the object). The policy server has 
> >similar multiple checks in its current state. I don't think 
> there is a 
> >problem if they overlap some as long as one isn't necessarilly a 
> >superset of another (which would just be redundant) which is not the 
> >case here since we are talking about different objects that can be 
> >labeled differently for any given query.
> 
> I'm confused. Password column is a good example - let's say 
> the password column is labeled at top secret, then how can a 
> secret user create a new row? I would assume a password would

Well, first of all a secret user can write a top secret column but I
think I know what you meant..
 
> be required, but that either means a secret user cannot read 
> or cannot write (or can't do either). If that's not the case, 
> then does that mean the row can be created without a 
> password? In which case, does that mean only top secret users 

Probably a trusted stored procedure that has a higher level of access
would be used

> can specify passwords? In which case, what does a password 
> provide. I may be missing something here, but seems the data
> (rows) should have labels and schema (columns) should be 
> validated using some other mechanism (e.g., ACL or similar). 

SELinux, using TE and MLS can be used to enforce any kind of security
policy on both the schema and the data. We should use the policy that we
have available to give policy flexibility (and postgres already has a
DAC like system for schema and data so it would be very much like Linux'
DAC+MAC setup)

> I would also think multiple security queries per database 
> query would present a significant performance hit (but then 
> again, that may be the price we have to pay for the added security).
> 

Many of the lookups are already going to be done (eg., table, column DAC
permissions) and the AVC is pretty fast, I don't think the hit will be
significant but I'd be very willing to find out..


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

Re: [RFC] SELinux and PostgreSQL

[Russell Coker]

On Friday 08 September 2006 12:10, "Joshua Brindle" <jbrindle@tresys.com> 
wrote:
> > I'm confused. Password column is a good example - let's say
> > the password column is labeled at top secret, then how can a
> > secret user create a new row? I would assume a password would
>
> Well, first of all a secret user can write a top secret column but I
> think I know what you meant..

Yes, in the MLS side of things the user can write-up (limited to the high 
level of their range unless there is an attribute on either the domain or the 
type to allow going higher).

But if you have the password labeled with a restrictive type (something 
equivalent to shadow_t) then it becomes a little more tricky.

> > be required, but that either means a secret user cannot read
> > or cannot write (or can't do either). If that's not the case,
> > then does that mean the row can be created without a
> > password? In which case, does that mean only top secret users
>
> Probably a trusted stored procedure that has a higher level of access
> would be used

Or a trusted SQL client program.  When considering ways of improving the 
security of database backed web sites my best ideas involved having multiple 
programs doing database access with different contexts.

For example the PHP script that wants to delete a topic might run a program 
that takes the user-name and password for the database connection on stdin 
(which would be used to validate the user's rights to delete the topic), and 
command-line parameters to specify the forum and topic to be deleted.  That 
way someone who cracks part of the forum software would only be able to 
delete topics that their UID is permitted to delete.

Also for database access I think we want permission for a trusted connection 
manager to perform connections on behalf of other contexts.  So we need to be 
able to specify in policy that domain foo_t can connect as bar_t and maybe 
permit range transitions too.  I expect this to be controversial.  But a very 
common need for database security is where you start with a front-end process 
that runs under the same context for all users.  There are several places 
where the privileges for different users can be separated, the database 
connection is one of them.

> > I would also think multiple security queries per database
> > query would present a significant performance hit (but then
> > again, that may be the price we have to pay for the added security).
>
> Many of the lookups are already going to be done (eg., table, column DAC
> permissions) and the AVC is pretty fast, I don't think the hit will be
> significant but I'd be very willing to find out..

I agree.  Lots of database operations can be CPU intensive, SE Linux checks 
with the AVC in user-space should not be a factor in overall performance.

Security Enhanced X is where we will have difficulty in delivering 
performance.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

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

RE: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

> From: Russell Coker [mailto:russell@coker.com.au] 
> 
> On Friday 08 September 2006 12:10, "Joshua Brindle" 
> <jbrindle@tresys.com>
> wrote:
> > > I'm confused. Password column is a good example - let's say the 
> > > password column is labeled at top secret, then how can a 
> secret user 
> > > create a new row? I would assume a password would
> >
> > Well, first of all a secret user can write a top secret 
> column but I 
> > think I know what you meant..
> 
> Yes, in the MLS side of things the user can write-up (limited 
> to the high level of their range unless there is an attribute 
> on either the domain or the type to allow going higher).
> 
> But if you have the password labeled with a restrictive type 
> (something equivalent to shadow_t) then it becomes a little 
> more tricky.
> 
> > > be required, but that either means a secret user cannot read or 
> > > cannot write (or can't do either). If that's not the 
> case, then does 
> > > that mean the row can be created without a password? In 
> which case, 
> > > does that mean only top secret users
> >
> > Probably a trusted stored procedure that has a higher level 
> of access 
> > would be used
> 
> Or a trusted SQL client program.  When considering ways of 
> improving the security of database backed web sites my best 
> ideas involved having multiple programs doing database access 
> with different contexts.
> 

Trusted stored procedures are nicer IMO. They allow a centralized way
for any other client to check eg., passwords. For example, instead of
being able to do select * from users where uid = '1'; and get the entire
row (including password) they would have to do fetch_my_user_row(1,
'mypassword'); and the stored proc would only return it if the password
matched the password in the row.

Even if the password column is hashed (which in most cases it will be)
its still better to force people to use stored procedures instead of
letting them get the entire table with hashed passwords to brute force
at their leasure.


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

Re: [RFC] SELinux and PostgreSQL

[KaiGai Kohei]

Russell Coker wrote:
> On Friday 08 September 2006 12:10, "Joshua Brindle" <jbrindle@tresys.com> 
> wrote:
>>> I'm confused. Password column is a good example - let's say
>>> the password column is labeled at top secret, then how can a
>>> secret user create a new row? I would assume a password would
>> Well, first of all a secret user can write a top secret column but I
>> think I know what you meant..
> 
> Yes, in the MLS side of things the user can write-up (limited to the high 
> level of their range unless there is an attribute on either the domain or the 
> type to allow going higher).
> 
> But if you have the password labeled with a restrictive type (something 
> equivalent to shadow_t) then it becomes a little more tricky.

When a unauthorized user try to insert a new row into the table which contains
the password column, I think an insert query without password column should be
allowed because this query doesn't write anything to the password column.
So, NULL or a default value of password column will be set on this query.

Because this selection is done by administrator, we cannot say the user touched
the sensitive column. How do you think this behavior?

I hope to explain by an example.
When the table FOOBAR has three columns (ID, NAME, PASSWORD) and user 'KaiGai'
does not have a permission to insert.
The following query (A) and (C) will be failed in this case, because 'KaiGai'
try to set anything into PASSWORD column. But the query (B) will succeed
because he doesn't set anything into there.

(A) insert into FOOBAR(ID, NAME, PASSWORD) values(123, 'KaiGai', 'xyz');
(B) insert into FOOBAR(ID, NAME) values(123, 'KaiGai');
(C) insert into FOOBAR(ID, NAME, PASSWORD) values(123, 'KaiGai', null);

>>> be required, but that either means a secret user cannot read
>>> or cannot write (or can't do either). If that's not the case,
>>> then does that mean the row can be created without a
>>> password? In which case, does that mean only top secret users
>> Probably a trusted stored procedure that has a higher level of access
>> would be used
> 
> Or a trusted SQL client program.  When considering ways of improving the 
> security of database backed web sites my best ideas involved having multiple 
> programs doing database access with different contexts.
> 
> For example the PHP script that wants to delete a topic might run a program 
> that takes the user-name and password for the database connection on stdin 
> (which would be used to validate the user's rights to delete the topic), and 
> command-line parameters to specify the forum and topic to be deleted.  That 
> way someone who cracks part of the forum software would only be able to 
> delete topics that their UID is permitted to delete.

I approve with the both ideas.
Anyway, an unauthorized user should not be able to access sensitive data
without passing any trusted procedure. I believe this behavior is general
in SELinux.

> Also for database access I think we want permission for a trusted connection 
> manager to perform connections on behalf of other contexts.  So we need to be 
> able to specify in policy that domain foo_t can connect as bar_t and maybe 
> permit range transitions too.  I expect this to be controversial.  But a very 
> common need for database security is where you start with a front-end process 
> that runs under the same context for all users.  There are several places 
> where the privileges for different users can be separated, the database 
> connection is one of them.
 >
>>> I would also think multiple security queries per database
>>> query would present a significant performance hit (but then
>>> again, that may be the price we have to pay for the added security).
>> Many of the lookups are already going to be done (eg., table, column DAC
>> permissions) and the AVC is pretty fast, I don't think the hit will be
>> significant but I'd be very willing to find out..
> 
> I agree.  Lots of database operations can be CPU intensive, SE Linux checks 
> with the AVC in user-space should not be a factor in overall performance.
> 
> Security Enhanced X is where we will have difficulty in delivering 
> performance.

In addition, PostgreSQL will optimize the query by sorting the conditions
and using index, so the priority of executing functions is low.
The evaluation by SELinux is not done for any rows.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL

[Joshua Brindle]

Joshua Brindle wrote:
>> From: Russell Coker [mailto:russell@coker.com.au] 
>>
>> On Friday 08 September 2006 00:28, KaiGai Kohei 
>> <kaigai@kaigai.gr.jp> wrote:
>>     
>>> The reason of this decision is that we cannot enforce 
>>>       
>> SELinux's access 
>>     
>>> controls to any tables, columns and rows, even if the proxy server 
>>> rewrite SQL statement.
>>>       
>> You want to label columns AND rows?
>>
>> How is that going to work?  I can understand the desire for 
>> this (EG have a password column in the user table), but the 
>> mechanism of enforcing this will be tricky to say the least.  
>> Will you perform two access checks on each cell, one for 
>> column and one for row?
> Columns are part of the schema, rows are data, they are different
> objects.
>
> You label columns because an entire column might contain important data
> (eg., a password). The rows are labeled because some domain X is putting
> data in them and you still want to be able to use policy to enforce
> information flow goals with the policy whether you are using kernel
> objects or userspace objects. In other words, if user X is topsecret and
> writes a row to a table you don't want user Y who is just secret to read
> it. 
>
> The latter can be accomplished in many ways including virtual databases
> (eg., views) or by modifying queries (like KaiGai mentioned in his first
> email) or filtering results or course grained labeling on tables so that
> each table is only 1 context. Some are better approaches than others, I
> won't go into that at this point..
>
> The answer is yes, there may be multiple security queries per database
> query, due to the data model of relational databases this is optimal and
> necessary IMO. This isn't abnormal either. Creating a file, for example,
> requires dir { add_name search}, file { create } and filesystem {
> associate } (for the object). The policy server has similar multiple
> checks in its current state. I don't think there is a problem if they
> overlap some as long as one isn't necessarilly a superset of another
> (which would just be redundant) which is not the case here since we are
> talking about different objects that can be labeled differently for any
> given query.
>
>   

Also note that this isn't very different from the way databases 
currently work. There are already permissions on databases, tables and 
columns and we'd (hopefully) be putting our access control hooks in the 
same places those checks are currently done. In addition to those checks 
we could implement row level access control using one of the above 
models or something else altogether. This is really about taking what 
the databases already have, making it mandatory and extending it, very 
much like what SELinux did for Linux.

There are also many very interesting and difficult problems like how one 
would label a result set that has rows from multiple tables with 
multiple rows of different contexts joined together. The approach taken 
above will guide one to the answers to questions like these. I'd be very 
interested in KaiGai's ultimate goals and how to best obtain those, both 
for himself and the greater community.

One other totally off topic comment.. MySQL already has much more of a 
'mandatory' policy than postgres. MySQL has no ownership of tables, 
databases and so on like postgres and doesn't allow discretionary 
permission changes. Not that its a problem but MySQL seems alot closer 
to the goal than postgres from an, admittedly superficial, security pov. 
I understand there are other issues like licensing, etc that makes 
postgres more friendly to this work though, depending on your motivation 
it may be worth it to shop around, in a manner of speaking.

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

Re: [RFC] SELinux and PostgreSQL

[KaiGai Kohei]

Because the SMTP server of my office was not allowed to deliver
SELinux-list, I posted it again from my house.
I'm sorry if you received same message twice.

Joshua Brindle wrote:
>> From: Russell Coker [mailto:russell@coker.com.au] 
>>
>> On Friday 08 September 2006 00:28, KaiGai Kohei 
>> <kaigai@kaigai.gr.jp> wrote:
>>> The reason of this decision is that we cannot enforce 
>> SELinux's access 
>>> controls to any tables, columns and rows, even if the proxy server 
>>> rewrite SQL statement.
>> You want to label columns AND rows?
>>
>> How is that going to work?  I can understand the desire for 
>> this (EG have a password column in the user table), but the 
>> mechanism of enforcing this will be tricky to say the least.  
>> Will you perform two access checks on each cell, one for 
>> column and one for row?
> 
> Columns are part of the schema, rows are data, they are different
> objects.

My opinion is same as Joshua's one.

In my planning implementation, the security context of targeted
tables and columns are checked before execution the given query,
and the transaction will be aborted if the client does not have
suitable permissions.
The filtering to rows are done during executing query by appended
condition (avs_has_perm() function).

I think it isn't tricky way.

Thanks,

> You label columns because an entire column might contain important data
> (eg., a password). The rows are labeled because some domain X is putting
> data in them and you still want to be able to use policy to enforce
> information flow goals with the policy whether you are using kernel
> objects or userspace objects. In other words, if user X is topsecret and
> writes a row to a table you don't want user Y who is just secret to read
> it. 
> 
> The latter can be accomplished in many ways including virtual databases
> (eg., views) or by modifying queries (like KaiGai mentioned in his first
> email) or filtering results or course grained labeling on tables so that
> each table is only 1 context. Some are better approaches than others, I
> won't go into that at this point..
> 
> The answer is yes, there may be multiple security queries per database
> query, due to the data model of relational databases this is optimal and
> necessary IMO. This isn't abnormal either. Creating a file, for example,
> requires dir { add_name search}, file { create } and filesystem {
> associate } (for the object). The policy server has similar multiple
> checks in its current state. I don't think there is a problem if they
> overlap some as long as one isn't necessarilly a superset of another
> (which would just be redundant) which is not the case here since we are
> talking about different objects that can be labeled differently for any
> given query.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL

[Richard Hally]

KaiGai Kohei wrote:
> Hello,
> 
> In recent days, I'm making a plan to enhance PostgreSQL with SELinux,
> and the followings are simple description about the plan currently
> I have.
> Any comments are so welcome. I want to revise the original design
> and security model before starting implementation.
> 
> I hope to release it within next one year, if possible. :)
> 
> * The basic idea
> The core facility of what I plan to enhance is an additional access
> control between the client of PostgreSQL and tables, columns, rows.
> (In future, the access control on binary large object(BLOB) is desirable.)
> 
> For the purpose, those database objects (table, column, row) must
> have capability to hold its security context. The security context
> of table and column can be stored in system catalog (pg_class and
> pg_attribute), and row's one will be stored in the row generated
> implicitlly.
> The security context of PostgreSQL client will be obtained via
> getpeercon().
> 
> I propose a new object class named as 'database' which contains the
> following access vectors.
> 
>   class database
>   {
>       createtbl
>       altertbl
>       droptbl
>       select
>       update
>       insert
>       delete
>       relabelfrom
>       relabelto
>   }
> 
> I propose some SQL functions reflecting to libselinux functions
> like avc_has_perm(), getpeercon() and so on. We can use them not
> only from SQL explicitly, but also implicitly appended to mask
> the result set.
> For example, the statement (B) will be actually executed when the
> server received the statement (A).
> 
> (A) select * from customer;
> 
> (B) select * from customer where avc_has_perm(getpeercon(),
>                                               security_context,
>                                               DATABASE__SELECT);
> 
> * The expected behavior
> 
> When we try to create a new table, the client must have 'createtbl'
> permission to the PostgreSQL server process. Then the created table
> inherits the security context of the server process.
> When we try to alter/drop a existing table, the client must have
> 'altertbl' or 'droptbl' permission to the targeted table.
> If the client didn't have suitable permissions, the transaction is
> aborted.
> 
> When we try to query with select statement, the client must have
> 'select' permission to all of the targeted table and column.
> And any rows on which the client didn'n have permission is eliminated
> from the result set.
> 
> When we try to query with insert statement, the client must have
> 'insert' permission to the targeted table and column. And any new
> rows are attached a new security context given by security_compute_create()
> with the client's context and the table's one.
> 
> When we try to query with update/delete, the client must have 'update'
> or 'delete' permission to the target table and column. And any rows on
> which the client didn't have permission is eliminated from the targets
> to update or delete.
> In addition, when we try to update the column contains security context,
> 'relabelfrom' and 'relabelto' are also evaluated.
> 
> * An example
> 
> +-------------------------------------------------------------------------+
> | TABLE: customer                                                         |
> +-------------------------------+-----+-----------+--------------+--------+
> |        security_context       | id  | name      |  address     | income |
> +-------------------------------+-----+-----------+--------------+--------+
> |system_u:object_r:pgrow_t:s0   | 100 | Onodera   | Hokkaido ... | 2000   |
> |system_u:object_r:pgrow_t:s0   | 101 | Hayashi   | Tokyo ...    | 2200   |
> |system_u:object_r:pgrow_t:s0:c0| 102 | Meguro    | Yokohama ... | 1800   |
> |system_u:object_r:pgrow_t:s0:c0| 103 | Terada    | Aomori ...   | 2100   |
> |system_u:object_r:pgrow_t:s0   | 104 | Motohashi | Kyoto ...    | 2500   |
> +-------------------------------+-----+-----------+--------------+--------+
> | [security contexts]                                                     |
> | table:  customer                  = system_u:object_r:postgresql_t:s0   |
> | column: customer.security_context = system_u:object_r:postgresql_t:s0   |
> | column: customer.id               = system_u:object_r:postgresql_t:s0   |
> | column: customer.name             = system_u:object_r:postgresql_t:s0   |
> | column: customer.mail             = system_u:object_r:postgresql_t:s0   |
> | column: customer.income           = system_u:object_r:postgresql_t:s0.c1|
> +-------------------------------------------------------------------------+
> 'income' is marked as different category, because it is a sensitive
> information in this case, and it's configured non-privileged client
> cannot access to some rows.
> 
> If the client context is user_u:system_r:unconfined_t:s0,
> an SQL statement of "select * from customer" will return the following
> result set.
> +-----+-----------+--------------+
> | id  | name      | address      |
> +-----+-----------+--------------+
> | 100 | Onodera   | Hokkaido ... |
> | 101 | Hayashi   | Tokyo ...    |
> | 104 | Motohashi | Kyoto ...    |
> +-----+-----------+--------------+
> 
> If the client context is user_u:system_r:unconfined_t:SystemLow-SystemHigh,
> the same SQL statement will return the following result set.
> +-----+-----------+--------------+--------+
> | id  | name      |  address     | income |
> +-----+-----------+--------------+--------+
> | 100 | Onodera   | Hokkaido ... | 2000   |
> | 101 | Hayashi   | Tokyo ...    | 2200   |
> | 102 | Meguro    | Yokohama ... | 1800   |
> | 103 | Terada    | Aomori ...   | 2100   |
> | 104 | Motohashi | Kyoto ...    | 2500   |
> +-----+-----------+--------------+--------+
> 
> (*) '*' is not extract into 'security_context' and the column on which
>     the client didn't have a permission.
> 
> Thanks for reading the long description.
> Any comments are welcome for me.

Hi,
	First question, how will this interact with the current "privileges"
mechanism in PostgreSQL (GRANT and REVOKE commands)?
Second, will there be a "user space security server" or will these
object classes be included in the kernel policy?

Thanks,
Richard Hally


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

Re: [RFC] SELinux and PostgreSQL

[KaiGai Kohei]

Because the SMTP server of my office was not allowed to deliver
SELinux-list, I posted it again from my house.
I'm sorry if you received same message twice.

> Hi,
> > 	First question, how will this interact with the current "privileges"
> > mechanism in PostgreSQL (GRANT and REVOKE commands)?

It's similar to the relationship between DAC and MAC on filesystem.
The mechanism I'm suggesting works purely an additional access control.
Thus any users's operations must be granted on PostgreSQL ACL and allowed
on SELinux security policy.

> > Second, will there be a "user space security server" or will these
> > object classes be included in the kernel policy?

The meaning is a bit unclear for me.
I intend to implement some libselinux functions into PostgreSQL
to enhance security functionality, and those functions referes
the kernel policy which will contain some new object classes.
Is is appropriate for the answer?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL (draft v2)

[KaiGai Kohei]

In recent days, I'm making a plan to enhance PostgreSQL with SELinux.
I posted the first draft of this plan a few days ago, and I got many
response. Thanks for your comments so much.
(Especially, Joshua and Russell)

The followings are the revised and summarized plan (draft v2).
I'm welcoming any comments to improve the project.


* New object classes and access vectors

Now, I plan to add some new object classes for databases, tables, stored
procedures, columns and rows. Those are defined as follows:

  class database
  {
      create
      alter
      drop
      relabelfrom
      relabelto
      access
      create_table
      drop_table
      create_procedure
      drop_procedure
      create_object
      drop_object
  }

  class table
  {
      create
      alter
      drop
      relabelfrom
      relabelto
      select
      update
      insert
      delete
  }

  class procedure
  {
      create
      alter
      drop
      relabelfrom
      relabelto
      execute
      entrypoint
  }

  class column
  {
      create
      alter
      drop
      relabelfrom
      relabelto
      select
      update
      insert
  #    delete
  }

  class row
  {
      relabelfrom
      relabelto
      select
      update
      insert
      delete
  }


* Labeling behavior
Some of database objects are labeled according to SELinux security policy
implicitly or by hand explicitly. The followings are labeling behaviors for
each object class.

- Labeling of database
The initial label is determined from security_compute_create() with the
the client process's label obtained from getpeercon() as a subject, the
server process's label as a object and database class.
We can also use ALTER DATABASE statement enhanced or update system catalog
(pg_database) to relabel explicitly, if relabelfrom/relabelto on database
class are allowed.

- Labeling of table
The initial label is determined from security_compute_create() with the
client, the database and table class.
We can also use ALTER TABLE statement enhanced or update system catalog
(pg_class) to relabel explicitly, if relabelfrom/relabelto on table class
are allowed.

- Labeling of stored procedure
The initial label is determined from security_compute_create() with the
client, the database and procedure class.
We can also use ALTER FUNCTION statement enhanced or update system catalog
(pg_proc) to relabel explicitly, if relabelfrom/relabelto on procedure class
are allowed.

- Labeling of column
The initial label is determined from security_compute_create() with the
client, the table and column class.
We can also use ALTER TABLE statement enhanced or update system catalog
(pg_attribute) to relabel explicitly, if relabelfrom/relabelto on column
class are allowed.

- on rows insertion
The initial label is determined from security_compute_create() with the
client, the table and row class.
We can also update the security_context column to relabel explicitly,
if relabelfrom/relabelto on row class are allowed.


* Remarkable behavior
- connection to PostgreSQL and select database
database:access is evaluated at first when the client connect to PostgreSQL
and choice the target database. If it's denied, connection will be closed.

- stored procedure
A stored procedure can be an entry point of domain transition.
It requires procedure:entrypoint permission and type_transition rule.
Using 'trusted stored procedure' with domain transition provids a method
to access sensitive data from unauthorized process.

For example, if the client doesn't have a permission on PASSWORD column,
he can access PASSWORD column via CHECK_PASSWORD() function marked as
a trusted stored procedure and cause domain transition.

- insert a new row
When we try to insert a new row into the table contains a column which
is not allowed to insert, we can insert a new row if enumerated columns
didn't contains the unauthorized column.
Then, this column will have NULL or default value. Because the client
cannot overwrite it on insertion, consistency is kept.

For example, we have a table defined as FOO(ID, NAME, PASSWORD).
When the client didn't have insert permission on PASSWORD, the (A) and
(C) of the following queries are failed.

(A) insert into FOOBAR(ID, NAME, PASSWORD) values(123, 'KaiGai', 'xyz');
(B) insert into FOOBAR(ID, NAME) values(123, 'KaiGai');
(C) insert into FOOBAR(ID, NAME, PASSWORD) values(123, 'KaiGai', null);

- delete a row
Becaues the delete opetation involves the whole of one row, column:delete
is not evaluated when we try to delete a row.
(Thus, it's not defined.)
This behavior may be a bit controvertible.

For example, it's one of the solution that deletion is not allowed without
permissions on the whole of columns on which the row has.

- interaction with PostgreSQL ACL mechanism
The SELinux enhancement works independently on PostgreSQL ACL.
It's similar to the relationship between DAC and MAC on filesystem.


Thanks for reading the long description.
Any comments are welcome for me.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL (draft v2)

[Russell Coker]

On Sunday 10 September 2006 14:55, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> In recent days, I'm making a plan to enhance PostgreSQL with SELinux.
> I posted the first draft of this plan a few days ago, and I got many
> response. Thanks for your comments so much.
> (Especially, Joshua and Russell)

Firstly, I didn't notice any getattr permission...

> - delete a row
> Becaues the delete opetation involves the whole of one row, column:delete
> is not evaluated when we try to delete a row.
> (Thus, it's not defined.)
> This behavior may be a bit controvertible.

Maybe the column object class could have an entry deletefrom which allows 
deleting a row that has an entry in that column.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

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

Re: [RFC] SELinux and PostgreSQL (draft v2)

[KaiGai Kohei]

Russell Coker wrote:
> On Sunday 10 September 2006 14:55, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>> In recent days, I'm making a plan to enhance PostgreSQL with SELinux.
>> I posted the first draft of this plan a few days ago, and I got many
>> response. Thanks for your comments so much.
>> (Especially, Joshua and Russell)
>
> Firstly, I didn't notice any getattr permission...

I also agreed your opinion.
But we have to pay attention on what select and getattr are always used
together on regular tables, because PostgreSQL packed metadata of each
column into result set.
(It's a purely implementation matter.)

In the special case, how should we consider the system catalog which is
the non-regular table contains only metadata?
I think a query for it should be purely handled as a metadata reference
operation, so only getattr is required for 'select * from pg_attribute;'
for example.

In addition, setattr is neccesary to control ALTER XXXX operations,
isn't it?

>> - delete a row
>> Becaues the delete opetation involves the whole of one row, column:delete
>> is not evaluated when we try to delete a row.
>> (Thus, it's not defined.)
>> This behavior may be a bit controvertible.
>
> Maybe the column object class could have an entry deletefrom which allows
> deleting a row that has an entry in that column.

It will solve the matter from TE viewpoint, but how dose it handle
the MLS/MCS constraint?
If the client must dominate any columns when a row is deleted, it seems
to me that the client must have the highest or upper clearance originally.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

RE: [RFC] SELinux and PostgreSQL (draft v2)

[Joshua Brindle]

> From: Kohei KaiGai [mailto:kaigai.kohei@gmail.com] On Behalf 
> Of KaiGai Kohei
> 
> Russell Coker wrote:
> > On Sunday 10 September 2006 14:55, KaiGai Kohei 
> <kaigai@kaigai.gr.jp> wrote:
> >> In recent days, I'm making a plan to enhance PostgreSQL 
> with SELinux.
> >> I posted the first draft of this plan a few days ago, and 
> I got many 
> >> response. Thanks for your comments so much.
> >> (Especially, Joshua and Russell)
> >
> > Firstly, I didn't notice any getattr permission...
> 
> I also agreed your opinion.
> But we have to pay attention on what select and getattr are 
> always used together on regular tables, because PostgreSQL 
> packed metadata of each column into result set.
> (It's a purely implementation matter.)
> 

Which includes all data and schema labels..

> In the special case, how should we consider the system 
> catalog which is the non-regular table contains only metadata?
> I think a query for it should be purely handled as a metadata 
> reference operation, so only getattr is required for 'select 
> * from pg_attribute;'
> for example.
> 
> In addition, setattr is neccesary to control ALTER XXXX 
> operations, isn't it?
> 

Sounds good.

> >> - delete a row
> >> Becaues the delete opetation involves the whole of one row, 
> >> column:delete is not evaluated when we try to delete a row.
> >> (Thus, it's not defined.)
> >> This behavior may be a bit controvertible.
> >
> > Maybe the column object class could have an entry deletefrom which 
> > allows deleting a row that has an entry in that column.
> 
> It will solve the matter from TE viewpoint, but how dose it 
> handle the MLS/MCS constraint?
> If the client must dominate any columns when a row is 
> deleted, it seems to me that the client must have the highest 
> or upper clearance originally.
> 

Only if the policy says that. Delete would be a write which means anyone
below it can do so. A worse problem is when someone is a high clearance
and can't delete a row because one of the fields is below him. I think
this makes the deletefrom permission unnecessarilly restrictive. It
might be sufficient to need delete on the table and row.


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

Re: [RFC] SELinux and PostgreSQL (draft v2)

[KaiGai Kohei]

>>> Firstly, I didn't notice any getattr permission...
>> I also agreed your opinion.
>> But we have to pay attention on what select and getattr are 
>> always used together on regular tables, because PostgreSQL 
>> packed metadata of each column into result set.
>> (It's a purely implementation matter.)
>>
> 
> Which includes all data and schema labels..

Of course, updating system catalog should be protected by
relabelfrom/relabelto and setattr permission, not only update.

>>>> - delete a row
>>>> Becaues the delete opetation involves the whole of one row, 
>>>> column:delete is not evaluated when we try to delete a row.
>>>> (Thus, it's not defined.)
>>>> This behavior may be a bit controvertible.
>>> Maybe the column object class could have an entry deletefrom which 
>>> allows deleting a row that has an entry in that column.
>> It will solve the matter from TE viewpoint, but how dose it 
>> handle the MLS/MCS constraint?
>> If the client must dominate any columns when a row is 
>> deleted, it seems to me that the client must have the highest 
>> or upper clearance originally.
>>
> 
> Only if the policy says that. Delete would be a write which means anyone
> below it can do so. A worse problem is when someone is a high clearance
> and can't delete a row because one of the fields is below him. I think
> this makes the deletefrom permission unnecessarilly restrictive. It
> might be sufficient to need delete on the table and row.

Indeed, it seems to me a bit strange behavior.
I also think row deletion should be controlled by table and row's permission.

Thanks.
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: [RFC] SELinux and PostgreSQL (draft v2)

[Russell Coker]

On Monday 11 September 2006 22:10, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
> > Maybe the column object class could have an entry deletefrom which allows
> > deleting a row that has an entry in that column.
>
> It will solve the matter from TE viewpoint, but how dose it handle
> the MLS/MCS constraint?
> If the client must dominate any columns when a row is deleted, it seems
> to me that the client must have the highest or upper clearance originally.

Note that SE Linux has a flexible implementation of MLS that is under the 
control of policy.

So it's not a case of "delete is write and therefore a high confidentiality 
process can't do it", it's something we can control by policy.  We can write 
policy that doesn't have a mlsconstraint to restrict the deletefrom 
operation, or that has some specific domain attribute to permit it.

Also currently the shadow password file has level s0 in MLS policy as 
protecting it is considered an issue of system integrity not confidentiality.  
A password column in a database might have the same requirements.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

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

Re: [RFC] SELinux and PostgreSQL (draft v2)

[Richard Hally]

KaiGai Kohei wrote:
> In recent days, I'm making a plan to enhance PostgreSQL with SELinux.
> I posted the first draft of this plan a few days ago, and I got many
> response. Thanks for your comments so much.
> (Especially, Joshua and Russell)
> 
> The followings are the revised and summarized plan (draft v2).
> I'm welcoming any comments to improve the project.
> 

Please help me understand why this addition is needed.
Would it be more appropriate to extend the existing roles and privileges
mechanism that already exists in PostgreSQL rather than adding all this
additional burden to the kernel object classes and access vector cache?
I can understand the need to extend access control the columns and rows
but most of the higher level controls already exist.

Thank you for your help,
Richard Hally


> * New object classes and access vectors
> 
<snip>


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

Re: [RFC] SELinux and PostgreSQL (draft v2)

[Joshua Brindle]

Richard Hally wrote:
> KaiGai Kohei wrote:
>   
>> In recent days, I'm making a plan to enhance PostgreSQL with SELinux.
>> I posted the first draft of this plan a few days ago, and I got many
>> response. Thanks for your comments so much.
>> (Especially, Joshua and Russell)
>>
>> The followings are the revised and summarized plan (draft v2).
>> I'm welcoming any comments to improve the project.
>>
>>     
>
> Please help me understand why this addition is needed.
> Would it be more appropriate to extend the existing roles and privileges
> mechanism that already exists in PostgreSQL rather than adding all this
> additional burden to the kernel object classes and access vector cache?
> I can understand the need to extend access control the columns and rows
> but most of the higher level controls already exist.
>
> Thank you for your help,
> Richard Hally
>
>   
It extends a proven MAC system to the database and allows us to have
centralized policies and use the already existing process labels. It
also allows the flexibility of SELinux (both mechanism and policy) to be
applied to the database without modifying the database server down the
line.

You can do privilege separation in the database system via process
labels instead of only by dbms role. This is analogous to using fine
grained types to break up root privileges.

Also, at some point (hopefully soon) we should be moving userspace
object class decision making to a userspace security server that can
provide answers to userspace object managers without the policy being in
unswappable kernel memory.

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

Re: [RFC] SELinux and PostgreSQL (draft v2)

[Russell Coker]

On Monday 11 September 2006 04:27, Joshua Brindle <method@gentoo.org> wrote:
> You can do privilege separation in the database system via process
> labels instead of only by dbms role. This is analogous to using fine
> grained types to break up root privileges.

Which also means that if two domains are not permitted to share data via files 
on disk then we can also be assured that they can't share data via the 
database.  As we want to be able to analyse policy and prove that it meets 
our security goals this is quite important.  Even if two users had different 
DBMS roles and the SE Linux access controls merely enforced the same access 
controls as the standard DBMS access control this would provide a benefit 
that would justify the existence of MAC support in the database for some 
users.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

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

Re: [RFC] SELinux and PostgreSQL (draft v2)

[Richard Hally]

Russell Coker wrote:
> On Monday 11 September 2006 04:27, Joshua Brindle <method@gentoo.org> wrote:
>> You can do privilege separation in the database system via process
>> labels instead of only by dbms role. This is analogous to using fine
>> grained types to break up root privileges.
> 
> Which also means that if two domains are not permitted to share data via files 
> on disk then we can also be assured that they can't share data via the 
> database.  As we want to be able to analyse policy and prove that it meets 
> our security goals this is quite important.  Even if two users had different 
> DBMS roles and the SE Linux access controls merely enforced the same access 
> controls as the standard DBMS access control this would provide a benefit 
> that would justify the existence of MAC support in the database for some 
> users.
> 
Thanks guys! It *will* add additional features (e.g. MLS) that are
unlikely to be included in the existing "roles and privileges".
This seems like the perfect use for a user space security server.
Any prognostication as to when that might appear?

Richard


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