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

​

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

​

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers