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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
