Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

From: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Date: 2009-10-28 13:50:18
Message-ID: 4AE84C1A.8080001@kaigai.gr.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera wrote:
> KaiGai Kohei escribió:
>
>> There are two cases when we create a new object.
>>
>> 1) create a new object without any explicit security context.
>> If we don't have statement support, it is the only case.
>> In this case, SELinux computes a default security context to be assigned
>> on the new object. It depends on the client's security context.
>> Then, it checks "create" permission on a pair of the client's security
>> context and the default security context. If not allowed, an error will
>> be raised.
>
> So, following this path, it is possible to write pg_dump support without
> a explicit security contexts: you have to make pg_dump write out the
> different tuples under different users. So you'd have more than one
> data object in the dump output for each table, one for every existing
> security context. This seems extremely difficult and intrusive however.
>
> It seems that having explicit security contexts in statements is
> necessary for this area to be reasonably simple.

Yes, it may be possible to restore the tables without statement, if we switch
OS-user's privilege for each tables, but unreasonable and unrealistic.

> Now, let's assume that COPY data includes the security context for each
> tuple in the output.

When we support row-level security, it will be necessary to backup and
restore the security context for each tuples.
What I'm talking about is how we specify the security context of the new
tables. If we can have statement support, it will be specified as follows:

CREATE TABLE t ( a int primary key, b text)
SECURITY_CONTEXT = 'system_u:object_r:sepgsql_ro_table_t:unclassified';

> How is that data restored? Would you need to
> grant super-SEPostgres privileges to the user restoring the data?

We need to restore the backup by the user who has privileges to create
database objects dumped at least. But no needs to have super-privilege.

For example, if all the dumped table are labeled as either "unclassified"
or "classified" but not "secret", all the needed privilege is to create
"unclassified" and "classified" tables, not "secret" table.

However, I expect that "unconfined" domain does the backup/restore works
expect for especially secure system. I don't think the default security
policy (such as ones bundled with Fedora) should restrict DBA's privileges
connected from the shell process.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-10-28 14:07:42 Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Previous Message Tom Lane 2009-10-28 13:43:48 Re: Where's the docs?