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

Bruce Momjian wrote:
> At this point I am so confused I don't have any response.

Are you discussing the case when we start a PostgreSQL with $PGDATA
generated by different binary?

At first, please consider the case when we start SE-PostgreSQL with
$PGDATA generated by vanilla binary.
(1) In this case, any stored tuple is not set HEAP_HASSECURITY on its
t_infomask, so SE-PostgreSQL considers it as a "unlabeled_t" one.

(2) In addition, we assumed the security system column was always available
independent from compile-time option. Thus, existing table definition
has security system column within its pg_attribute entries.

(3) Thus, SE-PostgreSQL allows users to access security field of existing
tuples via the security column. Maybe, it returns "unlabeled_t" security
context, so we have to label it properly.

(4) In another point of view, how the security system column work in the
vanilla PostgreSQL? Because it does not available any guest on PGACE,
HEAP_HASSECURITY is not always set. It means we cannot set any value on
the security field via security system column, and reading the column
always returns dummy data (empty text).

In the reversed case, the vanilla PostgreSQL simply ignores security
field independent from HEAP_HASSECURITY. When it inserts/update a tuple,
it does not has its security field and lost its security attribute.
It is quite natural.

Does it help you to understand?

> ---------------------------------------------------------------------------
> 
> KaiGai Kohei wrote:
>>>> But SE-PostgreSQL does not need its table option to control
>>>> its availability per table granuality due to its security model.
>>>>
>>>> Database ACL is a kind of DAC. It allows resource owners to
>>>> set up its access rights. In other hand, SE-PostgreSQL is an
>>>> implementation of MAC. It does not allow owners to control its
>>>> access rights. This is the role of centralized security policy,
>>> It is fine if you require SECEXT to be on for SE-Linux, but the option
>>> must be available for non-SE-Linux so you can load dumps from either
>>> Postgres configuration, and /data is compatible with both versions.
>> It is unclear for me why you thought this option is necessary to load
>> dumps generated by vanilla PostgreSQL?
>> I assumes the security column should be always available, so we don't
>> need to add a column when SE-PostgreSQL load a vanilla $PGDATA.
>>
>>>>> When SE-Linux is enabled, CREATE TABLE would issue an error if SECEXT
>>>>> was false.  I can't think of a clean way to guarantee that existing
>>>>> tables have SECEXT though, which means we might need to have a missing
>>>>> 'security_context' column mean default SE-Linux permissions.
>>>> SE-PostgreSQL stores its security context on the security field of
>>>> HeapTupleHeader and set HEAP_HASSECURITY of t_infomask.
>>>> The security system column is always available, so it does not make
>>>> any matter. When no guest is available on PGACE, HEAP_HASSECURITY of
>>>> t_infomask is not set, so security field is not allocated and NULL
>>>> bitmask is not polluted.
>>> If you make an SE-Linux dump with security fields, how will that be
>>> loadable in a non-SE-Linux Postgres database?
>> In this case, user should no dump his database with security field.
>> The patched pg_dump does not dump security field without
>> '--security-context' option.
>>
>>> We are also going to need ALTER TABLE to be able to add/remove these
>>> columns from tables, like OIDs.
>> I don't agree.
>> The "security column" (not a "acl column") should be always exist.
>> In the vanilla binary, it simply returns NULL or empty string, so there is
>> no waste of storage consumption.
>> It is worthful when we run SE- binary with $PGDATA generated by vanilla one.
>> Any stored tuple does not have security field, but it gives DBAs a chance to
>> relabel them via the "security column".
>>
>>>>  >> If we assume users set up Row-level ACLs for specific tables, per-table
>>>>  >> option is meaningful for reduction of NULL-bitmap space in the tuple
>>>>  >> without any NULL-values on general columns.
>>>>  >
>>>>  > Right.  I was hoping there was a way to have HEAP_HASSECACL control if
>>>>  > the value is present or not.
>>>>  >
>>>>  > I sure wish others were adding ideas to this discussion.
>>>>
>>>> I have a plan to add a new field (declared as "int2 relrowacl") into
>>>> pg_class to show what column stores its Row-level ACLs.
>>>> When we create a table with (ROWACL=TRUE), it implicitly add a column
>>>> declared as "security_acl aclitem[]", and its attribute number is
>>>> stored within the "pg_class.relrowacl". If it has positive value,
>>>> tuples within the table can have its individual ACLs. No-ACL is
>>>> represented via the NULL-bitmap. If it is zero, the table does not
>>>> have the "security_acl" column, and the row-level controls are simply
>>>> ignored.
>>> I am confused why we would want this instead of the way we do oids.
>> It enables to implement the hardcoded row-acl more simple.
>> It allows to store variable length ACLs using existing mechanism, and
>> makes unnecessary to translate between ACLs and raw text representation.
>>
>>
>> Thanks,
>