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

Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> The other one is it has two kind of reader permissions ("select" and
>> "use").
>> The "select" permission is applied when user tries to read tables/columns
>> and its contents are returned to the user.
>> The "use" permission is applied when user tries to read table/columns,
>> but its contents are consumed internally (not returned to user directly).
>>
>> For example:
>> SELECT a, b FROM t WHERE b > 10 and c = 'aaa';
>>
>> In this case,
>> db_column:{select} permission is applied on "t.a".
>> db_column:{select use} permission is applied on "t.b".
>> db_column:{use} permission is applied on "t.c".
>> db_table:{select use} permission is applied on "t"
>>
>> However, I don't absolutely oppose to integrate them into a single
>> reader "select" permission, because it was originally a single
>> permission, then "use" is added.
>
> If you have "use" permisson on c, you can easily use it to find out the
> exact value. Just do queries like "SELECT 'foo' FROM t WHERE b > 10 AND
> c = 'aaa' AND c BETWEEN 1 AND 1000" repeatedly with different ranges to
> zoom into the exact value. So I think separating those two permissions
> is a mistake,

Hmm.
At least, I can agree to integrate these two permissions into a single
"select". It is originally upper compatible to "use".

>> Please note that user's privileges are not limited to create/alter/drop
>> them. One sensitive permission is "db_procedure:{install}".
>> It is checked when user defined functions are set up as a function
>> internally invoked.
>>
>> For example, "pg_conversion.conproc" is internally invoked to translate
>> a text, but it does not check pg_proc_aclcheck() in runtime.
>> We consider all user defined functions should be checked either of:
>> - "db_procedure:{execute}" permission for the client in runtime
>> or
>> - "db_procedure:{install}" permission for the DBA on installation time
>>
>> Needless to say, "{install}" is more sensitive permission because it
>> means anyones to invoke it implicitly. So, the default policy only
>> allows it on functions defined by DBA, but the "execute" permission
>> is allowed normal users to invoke functions defined by himself.
>
> Hmm. We normally rely on the fact that a conversion function needs to be
> a C-function, and because only superusers can create C-functions we have
> assumed that they're safe to call. Which was actually not true until
> recently, when we added checks into all the conversion functions to
> check that the source and target encoding of the strings passed as
> arguments match the ones specified in the CREATE CONVERSION command.
>
> There has been talks of making CREATE CONVERSION superuser-only, so we
> could easily just do that. Can you give some other examples of where the
> "install" permission is used?

Because SE-PostgreSQL works orthogonally to the existing access controls,
so we need to consider two cases.
a) A superuser connected from unprivileged domain (like: user_t, httpd_t)
b) A superuser connected from privileged domain (like: sysadm_t, unconfined_t)

The superuser is a concept of PostgreSQL, and the domain is a concept
of SELinux. It seems to me you assumes the b) case.

The a) case should be focused on here.
In the a) case, SE-PostgreSQL does not prevent to create C-function
(as far as shared library has an appropriate label: "lib_t"), and newly
created functions are labeled as "unpriv-user defined functions" which
depends on the domain.

It allows unpriv-domains to invoke functions defined by himself,
but does not allow to "install" as a conversion and others, because
it can be implicitly used by other domains.

NOTE: unprivileged domain cannot create files labeled as "lib_t" on the
operating system, so all they can do is to load libraries already
set up.

Our assumption is a client connected from user_t or httpd_t is suspicious,
even if they logged in as a superuser, so SE-PostgreSQL applies additional
checks.

> But if I've understood correctly, one goal is to restrict the actions of
> superusers as well. Is there something to disallow superusers from
> creating C-functions? If yes, isn't that enough protection from things
> like the conversion functions?

Please note that SE-PostgreSQL focuses on the domain a client connected
from, not attributes of database user.
(Needless to say, vanilla PostgreSQL concurrently prevents C-functions
by normal database users.)

The conversion is an example of "install" permissions.
The list of functions to be checked are here.
http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/hooks.c#446

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