Re: trust authentication behavior

----- Ursprüngliche Mail -----
Von: "Kohei KaiGai" <kaigai@kaigai.gr.jp>
An: "Robert Haas" <robertmhaas@gmail.com>
CC: "David G. Johnston" <david.g.johnston@gmail.com>, "Denis Kirjanov" <kda@itsirius.su>, pgsql-hackers@postgresql.org,
"KoheiKaiGai" <kaigai@ak.jp.nec.com> 
Gesendet: Samstag, 16. Mai 2015 03:32:55
Betreff: Re: [HACKERS] trust authentication behavior

2015-05-16 5:13 GMT+09:00 Robert Haas <robertmhaas@gmail.com>:
> On Thu, May 14, 2015 at 3:52 PM, David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> On Thu, May 14, 2015 at 12:22 PM, Denis Kirjanov <kda@itsirius.su> wrote:
>>>
>>> Yeah, but the idea is to do that without the pg_hba.conf
>>
>> You may want to try describing the problem and not just ask if the chosen
>> solution is possible - of which I am doubtful but I have never used selinux
>> or studied it in any depth.  pg_hba.conf is the chosen tool for this kind of
>> thing so pointing out why it cannot be used is a much more useful first
>> step.
>
> In mandatory access control systems like SE-Linux, the system security
> policy is supposed to centralize all security decisions, and it should
> be possible to enforce any necessary access control rule by modifying
> that policy.  At least that's my understanding.  sepgsql lets the
> kernel's mandatory access control policies filter down into access
> control decisions that PostgreSQL makes.  sepgsql consults the
> operating system policy when faced with an access control decision of
> a type that it supports, and accepts or rejects the connect based on
> that.
>
> So the question is whether the sepgsql integration points include
> anything that can block a connection, rather than, say, allowing the
> connection but blocking access to particular tables.  Looking at the
> code, it appears that it vaguely contemplates a db_database:{access}
> permission, which sounds like about the right thing, and it's also
> mentioned at https://wiki.postgresql.org/wiki/SEPostgreSQL/Permissions#Connection
> as maybe being the right thing, but I can't find anyplace that it is
> actually enforce.  That's rather disappointing...
>
> KaiGai, any thoughts?
>
I'd like to understand what Denis Kirjanov actually wants to do
first of all.

If he wants to control accesses whole of the PostgreSQL instances
according to the credential on operating system, it is a configuration
on operating system side.
He can write up self security policy module that allows "someone_t"
domain to connect PostgreSQL instance, not per database basis.
It is permission around the pair of someone_t and postgresql_t, than
can be wrapped up by postgresql_stream_connect() in selinux's policy.

If he wants to control accesses per database basis based on selinux
policy, it is a right choice to consider sepgsql module.
However, some of permissions are not still implemented, like
db_database:{access} because of priority of permissions (and I had to
focus on GPU acceleration infrastructure in v9.5 cycle...).

If he wants to control accesses based on the credential of operating
system, not limited to selinux, IDENT method is available, isn't it?

Also, he may additionally needs labeled networking configuration,
if he wants to carry security label information over the TCP/IP
connection. It is a point to be considered for his requirement.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
----- Ursprüngliche Mail -----


The idea is to put all the security decisions into the selinux policy.
As I wrote before it concerns the security label command behavior(done through the policy) and
the incoming connections (for now it's incoming  remove trust-based)

Thanks!