Re: [HACKERS] trust authentication behavior
2015-05-18 15:15 GMT+09:00 Denis Kirjanov :
>
>
> - Ursprüngliche Mail -
> Von: "Kohei KaiGai"
> An: "Robert Haas"
> CC: "David G. Johnston" , "Denis Kirjanov"
> , pgsql-hackers@postgresql.org, "Kohei KaiGai"
>
> Gesendet: Samstag, 16. Mai 2015 03:32:55
> Betreff: Re: [HACKERS] trust authentication behavior
>
> 2015-05-16 5:13 GMT+09:00 Robert Haas :
>> On Thu, May 14, 2015 at 3:52 PM, David G. Johnston
>> wrote:
>>> On Thu, May 14, 2015 at 12:22 PM, Denis Kirjanov 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
> - 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trust authentication behavior
- Ursprüngliche Mail -
Von: "Kohei KaiGai"
An: "Robert Haas"
CC: "David G. Johnston" , "Denis Kirjanov"
, pgsql-hackers@postgresql.org, "Kohei KaiGai"
Gesendet: Samstag, 16. Mai 2015 03:32:55
Betreff: Re: [HACKERS] trust authentication behavior
2015-05-16 5:13 GMT+09:00 Robert Haas :
> On Thu, May 14, 2015 at 3:52 PM, David G. Johnston
> wrote:
>> On Thu, May 14, 2015 at 12:22 PM, Denis Kirjanov 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
- 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
Re: [HACKERS] trust authentication behavior
2015-05-16 5:13 GMT+09:00 Robert Haas :
> On Thu, May 14, 2015 at 3:52 PM, David G. Johnston
> wrote:
>> On Thu, May 14, 2015 at 12:22 PM, Denis Kirjanov 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] trust authentication behavior
On Thu, May 14, 2015 at 3:52 PM, David G. Johnston
wrote:
> On Thu, May 14, 2015 at 12:22 PM, Denis Kirjanov 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
Re: [HACKERS] trust authentication behavior
On Thu, May 14, 2015 at 12:22 PM, Denis Kirjanov 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: [HACKERS] trust authentication behavior
Yeah, but the idea is to do that without the pg_hba.conf - Ursprüngliche Mail - Von: "David G. Johnston" An: "Denis Kirjanov" 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 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
Re: [HACKERS] trust authentication behavior
Andrew Dunstan writes: > On 05/14/2015 11:59 AM, Robert Haas wrote: >> On Thu, May 14, 2015 at 5:16 AM, Denis Kirjanov 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
Re: [HACKERS] trust authentication behavior
On 05/14/2015 11:59 AM, Robert Haas wrote: On Thu, May 14, 2015 at 5:16 AM, Denis Kirjanov 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
Re: [HACKERS] trust authentication behavior
On Thu, May 14, 2015 at 5:16 AM, Denis Kirjanov 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
Re: [HACKERS] trust authentication behavior
On Thu, May 14, 2015 at 2:16 AM, Denis Kirjanov 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
[HACKERS] trust authentication behavior
Hello guys, Is it possible to restrict the trust auth method to accept local connections only using the selinux policy? Thank you! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
