Re: [PATCH] SE-PgSQL/tiny rev.2193

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193
Date: 2009-07-17 03:10:12
Message-ID: 603c8f070907162010i1ab361den993bb0d1b6b48fcc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/7/16 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> Yes, the tiny version will not give any advantages in security without
> future enhancements.
> It is not difficult to add object classes and permissions.
> If necessary, I'll add checks them with corresponding permissions.
>
> One anxiety is PostgreSQL specific object class, such as LANGUAGE.
> It's not clear for me whether the maintainer of the SELinux security
> policy accept these kind of object classes, or not.
> I would like to implement them except for PostgreSQL specific object
> class in this phase.

I'm starting to think that there's just no hope of this matching up
well enough with the way PostgreSQL already works to have a chance of
being accepted.

> Here is a few differences in access control model between PostgreSQL and
> SELinux, so I could not map all the SELinux permissions on the pg_xxx_aclcheck()
> mechanism.
>
> For example, ExecCheckRTEPerms() checks permissions on the tables and
> columns appeared in the user given query. When the user have SELECT
> permission on the required table, it bypasses to check permissions on
> the columns.
> SELinux's security model needs to check permissions on all the required
> objects. For example, "SELECT A,B FROM T" requires the client to have
> db_table:{select} on T and db_column:{select} on A and B.

Isn't this a purely arbitrary decision on your part to implement
incompatible semantics? I don't see why it can't check for
db_table:{select} and if that fails then check for db_column:[select}
on each column? Maybe that's not legit, I don't understand SE-Linux
well enough to know. But I think we need to get someone from the
SE-Linux community involved to help review and consider these kinds of
issues, because it is obvious that we don't have the expertise in the
PostgreSQL community.

> For other example, some of pg_xxx_aclcheck() is bypassed when the client
> has superuser privilege. In this case, SELinux requires the client to
> have both of db_database:{superuser} and a certain permission.

Surely you can't just transform (A OR B) into (A AND B) and pretend
that's the same thing...

> Sorry, I could not read it from the previous suggestions.
> If you have been suggesting it repeatedly, I'm sorry so much.

I think the language barrier is part of what is making this a very
difficult process. Your English is surely better than my Japanese,
but we are definitely going around in circles.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Itagaki Takahiro 2009-07-17 03:56:29 Re: COPY WITH CSV FORCE QUOTE * -- REVIEW
Previous Message KaiGai Kohei 2009-07-17 02:58:02 Re: [PATCH] SE-PgSQL/tiny rev.2193