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

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, 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 08:33:52
Message-ID: 4AE801F0.6030202@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> Robert Haas wrote:
>>> 2009/10/27 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>> - no statement support to specify security context.
>>>> (It makes impossible to add support in pg_dump. Is it really OK?)
>>> I doubt that anything without pg_dump support would be even vaguely OK...
>> In my previous experience, it enabled to reduce 300-400 lines of the patch.
>> But here is no more sense than the 300-400 lines.
>>
>> In my honest, I like to include a feature to specify an explicit security
>> context in the patch from the begining.
>> (It also allows to attach test cases with more variations.)
>
> Can you explain why that's required for pg_dump support? I was thinking
> that there would be no explicit security labels on objects, and
> permissions would be checked based on other inherent properties of the
> object, like owner, name, schema etc.

In SELinux model, security context is the only property which can be
used to decision making based on the security policy.
It never uses any other properties, like owner, name, ...

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.

2) create a new object with an explicit security context.
In this case, the given explicit security context will be assigned.
SELinux checks "create" permission on a pair of the client's security
context and the given explicit security context. If not allowed, an error
will be raised.

Please note that SELinux assigns a security context on the managed object
in either cases.

If we don't have any statement support, there are no way to specify
an explicit security context on the new object in creation.
It also means we cannot recover the security context of objects correctly.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2009-10-28 09:37:49 Re: Parsing config files in a directory
Previous Message Heikki Linnakangas 2009-10-28 08:03:40 Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))