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

Heikki Linnakangas wrote:
> This seems to be a recurring theme with this patch. We stripped
> row-level permissions, now we have SET/SHOW and the "function
> installation" permissions. And the read/write file permissions. To make
> progress, we need to consider each new feature like that separately, as
> separate patches.
>
> KaiGei: Let's drop SET/SHOW permissions from the patch, I presume that's
> not critical for the overall goal.

OK, its significance is relatively low.

> Dropping the "function installation" permissions would simplify the
> patch a lot. It would make the patch as whole a lot easier to swallow.
> Let's ask the same question as with the row-level permissions: If we
> drop the function installation stuff, would the rest of the patch still
> be useful? We can revisit that part in the future.

As far as we have the idea of "superuser" permission on SELinux also,
we can do it later.

> I have the same concern as Tom about trying to curtail what superusers
> can do. We have not been concerned about what a superuser can and can't
> do before, so there could be small loopholes all over the codebase that
> we haven't thought about. Just as an example, you added checks to COPY
> to prevent reads from/writes to files. That's restricted to superusers.
> However, you left pg_read_file() in src/backend/utils/adt/genfile.c wide
> open.

Oops, it was my overlooks.

> If we drop the goal of trying to restrict what a superuser can do, is
> the patch still useful?

I want to keep permission checks on files specified by users, because
the "superuser" permission affects very wide scope, and all or nothing
policy in other word.
However, the combination of clients and files is not so simple, and
I think it is necessary to apply permission checks individually.

I can agree to postpone the checks for procedure installation,
C-libraries installation/loading.

> One idea is to add a single "is superuser" permission to sepgsql. That
> can be checked in a single place: superuser_arg(). If SE-Linux says that
> you don't have superuser permissions, then superuser() will return false
> even if the current user is marked as a superuser in pg_role. It would
> give the same level of protection as sprinkling those fine-grained
> checks all over the code, just in a more coarse-grain fashion.

At least, I think it is not a strange design.
In-kernel SELinux also has similar permission (capability class) to
restrict root privileges, in additon to the invididual checks.
(NOTE: In Linux, root privilges is a set of capability.)

Maybe, I can submit the revised patch within 1.5 days.
Please wait for a while.

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