Re: trust authentication behavior - Mailing list pgsql-hackers

2015-05-18 15:15 GMT+09:00 Denis Kirjanov <kda@itsirius.su>:
>
>
> ----- 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,"Kohei KaiGai" <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.
>
Yep, it is fundamental idea of sepgsql module.

> 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)
>
Are you concerning about client's security label when connection
comes over TCP/IP network? Or, something other concern??

If you want to get client's label over tcp/ip network, you need
additional configuration on peer-to-peer ipsec to exchange security
label over the network.
Elsewhere, selinux also offers a mechanism to assign client's
security label based on the source ip address.

If you have other concern, please introduce it.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>