Thread: trust authentication behavior

trust authentication behavior

From
Denis Kirjanov
Date:
Hello guys,

Is it possible to restrict the trust auth method to accept local connections only using the selinux policy?

Thank you!



Re: trust authentication behavior

From
"David G. Johnston"
Date:
On Thu, May 14, 2015 at 2:16 AM, Denis Kirjanov <kda@itsirius.su> wrote:
Hello guys,

Is it possible to restrict the trust auth method to accept local connections only using the selinux policy?

You want selinux to prevent trust connections from non-local clients even if pg_hba.conf explicitly allows them?

David J

 

Re: trust authentication behavior

From
Robert Haas
Date:
On Thu, May 14, 2015 at 5:16 AM, Denis Kirjanov <kda@itsirius.su> wrote:
> Is it possible to restrict the trust auth method to accept local connections only using the selinux policy?

I would guess that it probably is, but I can't tell you how.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: trust authentication behavior

From
Andrew Dunstan
Date:
On 05/14/2015 11:59 AM, Robert Haas wrote:
> On Thu, May 14, 2015 at 5:16 AM, Denis Kirjanov <kda@itsirius.su> wrote:
>> Is it possible to restrict the trust auth method to accept local connections only using the selinux policy?
> I would guess that it probably is, but I can't tell you how.
>

I would have guessed not :-)

cheers

andrew



Re: trust authentication behavior

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> writes:
> On 05/14/2015 11:59 AM, Robert Haas wrote:
>> On Thu, May 14, 2015 at 5:16 AM, Denis Kirjanov <kda@itsirius.su> wrote:
>>> Is it possible to restrict the trust auth method to accept local connections only using the selinux policy?

>> I would guess that it probably is, but I can't tell you how.

> I would have guessed not :-)

Yeah.  AFAIK selinux is strictly a kernel-level facility so it can only
enforce things that are visible to the kernel.  PG's choice of auth
method isn't.
        regards, tom lane



Re: trust authentication behavior

From
Denis Kirjanov
Date:
Yeah, but the idea is to do that without the pg_hba.conf

----- Ursprüngliche Mail -----
Von: "David G. Johnston" <david.g.johnston@gmail.com>
An: "Denis Kirjanov" <kda@itsirius.su>
CC: pgsql-hackers@postgresql.org
Gesendet: Donnerstag, 14. Mai 2015 18:22:45
Betreff: Re: [HACKERS] trust authentication behavior

On Thu, May 14, 2015 at 2:16 AM, Denis Kirjanov <kda@itsirius.su> wrote:

> Hello guys,
>
> Is it possible to restrict the trust auth method to accept local
> connections only using the selinux policy?
>

You want selinux to prevent trust connections from non-local clients even
if pg_hba.conf explicitly allows them?

David J

​



Re: trust authentication behavior

From
"David G. Johnston"
Date:
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.

David J.

Re: trust authentication behavior

From
Robert Haas
Date:
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?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: trust authentication behavior

From
Kohei KaiGai
Date:
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>



Re: trust authentication behavior

From
Denis Kirjanov
Date:

----- 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!



Re: trust authentication behavior

From
Kohei KaiGai
Date:
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>