Multi-tenancy with RLS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
63 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Robert Haas
On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost <[hidden email]> wrote:
>> Whereupon you'd have no certainty that what you got represented a
>> complete dump of your own data.
>
> It would be a dump of what you're allowed to see, rather than an error
> saying you couldn't dump something you couldn't see, which is the
> alternative we're talking about here.  Even if you've got a dependency
> to something-or-other, if you don't have access to it, then you're
> going to get an error.

I think you're dismissing Tom's concerns far too lightly.  The
row_security=off mode, which is the default, becomes unusable for
non-superusers under this proposal.  That's bad.  And if you switch to
the other mode, then you might accidentally fail to get all of the
data in some table you're trying to back up.  That's bad too: that's
why it isn't the default.  There's a big difference between saying
"I'm OK with not dumping the tables I can't see" and "I'm OK with not
dumping all of the data in some table I *can* see".

It seems to me that there's a big difference between policies we ship
out of the box and policies that are created be users: specifically,
the former can be assumed benign, while the latter can't.  I think
that difference matters here, although I'm not sure exactly where to
go with it.

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


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Joe Conway
On 02/09/2016 11:47 AM, Robert Haas wrote:

> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost <[hidden email]> wrote:
>>> Whereupon you'd have no certainty that what you got represented a
>>> complete dump of your own data.
>>
>> It would be a dump of what you're allowed to see, rather than an error
>> saying you couldn't dump something you couldn't see, which is the
>> alternative we're talking about here.  Even if you've got a dependency
>> to something-or-other, if you don't have access to it, then you're
>> going to get an error.
>
> I think you're dismissing Tom's concerns far too lightly.  The
> row_security=off mode, which is the default, becomes unusable for
> non-superusers under this proposal.  That's bad.  And if you switch to
> the other mode, then you might accidentally fail to get all of the
> data in some table you're trying to back up.  That's bad too: that's
> why it isn't the default.  There's a big difference between saying
> "I'm OK with not dumping the tables I can't see" and "I'm OK with not
> dumping all of the data in some table I *can* see".
I don't grok what you're saying here. If I, as a non-superuser could
somehow see all the rows in a table just by running pg_dump, including
rows that I could not normally see due to RLS policies, *that* would be
bad. I should have no expectation of being able to dump rows I can't
normally see.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Robert Haas
On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway <[hidden email]> wrote:

> On 02/09/2016 11:47 AM, Robert Haas wrote:
>> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost <[hidden email]> wrote:
>>>> Whereupon you'd have no certainty that what you got represented a
>>>> complete dump of your own data.
>>>
>>> It would be a dump of what you're allowed to see, rather than an error
>>> saying you couldn't dump something you couldn't see, which is the
>>> alternative we're talking about here.  Even if you've got a dependency
>>> to something-or-other, if you don't have access to it, then you're
>>> going to get an error.
>>
>> I think you're dismissing Tom's concerns far too lightly.  The
>> row_security=off mode, which is the default, becomes unusable for
>> non-superusers under this proposal.  That's bad.  And if you switch to
>> the other mode, then you might accidentally fail to get all of the
>> data in some table you're trying to back up.  That's bad too: that's
>> why it isn't the default.  There's a big difference between saying
>> "I'm OK with not dumping the tables I can't see" and "I'm OK with not
>> dumping all of the data in some table I *can* see".
>
> I don't grok what you're saying here. If I, as a non-superuser could
> somehow see all the rows in a table just by running pg_dump, including
> rows that I could not normally see due to RLS policies, *that* would be
> bad. I should have no expectation of being able to dump rows I can't
> normally see.

That's true.  But I should also have an expectation that running
pg_dump won't trigger arbitrary code execution, which is why by
default, pg_dump sets row_security to OFF.  That way, if a row
security policy applies, I get an error rather than an incomplete,
possibly-invalid dump (and arbitrary code execution on the server
side).  If I'm OK with doing the dump subject to row security, I can
rerun with --enable-row-security.  But this proposal would force
non-superusers to always use that option, and that's not a good idea.

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


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Joshua D. Drake
On 02/09/2016 12:05 PM, Robert Haas wrote:

> That's true.  But I should also have an expectation that running
> pg_dump won't trigger arbitrary code execution, which is why by
> default, pg_dump sets row_security to OFF.  That way, if a row
> security policy applies, I get an error rather than an incomplete,
> possibly-invalid dump (and arbitrary code execution on the server
> side).  If I'm OK with doing the dump subject to row security, I can
> rerun with --enable-row-security.  But this proposal would force
> non-superusers to always use that option, and that's not a good idea.
>

If I understand correctly what we are talking about here is:

1. If RLS is enabled and a non-super user issues a pg_dump, it will
error unless I issue --enable-row-security

2. If RLS is not enabled and a non-super user issues a pg_dump the
behavior is basically what it is now.

3. If RLS is enabled or not and I am a super user, it doesn't matter
either way.

 From my perspective, I should not have to enable row security as a
non-super user to take a pg_dump. It should just work for what I am
allowed to see. In other words:

pg_dump -U $non-super_user

Should just work, period.

Sincerely,

Joshua D. Drake

--
Command Prompt, Inc.                  http://the.postgres.company/
                         +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Stephen Frost
In reply to this post by Robert Haas
Robert,

* Robert Haas ([hidden email]) wrote:

> On Tue, Feb 9, 2016 at 3:01 PM, Joe Conway <[hidden email]> wrote:
> > On 02/09/2016 11:47 AM, Robert Haas wrote:
> >> On Fri, Jan 15, 2016 at 11:53 AM, Stephen Frost <[hidden email]> wrote:
> >>>> Whereupon you'd have no certainty that what you got represented a
> >>>> complete dump of your own data.
> >>>
> >>> It would be a dump of what you're allowed to see, rather than an error
> >>> saying you couldn't dump something you couldn't see, which is the
> >>> alternative we're talking about here.  Even if you've got a dependency
> >>> to something-or-other, if you don't have access to it, then you're
> >>> going to get an error.
> >>
> >> I think you're dismissing Tom's concerns far too lightly.  The
> >> row_security=off mode, which is the default, becomes unusable for
> >> non-superusers under this proposal.  That's bad.  And if you switch to
> >> the other mode, then you might accidentally fail to get all of the
> >> data in some table you're trying to back up.  That's bad too: that's
> >> why it isn't the default.  There's a big difference between saying
> >> "I'm OK with not dumping the tables I can't see" and "I'm OK with not
> >> dumping all of the data in some table I *can* see".
> >
> > I don't grok what you're saying here. If I, as a non-superuser could
> > somehow see all the rows in a table just by running pg_dump, including
> > rows that I could not normally see due to RLS policies, *that* would be
> > bad. I should have no expectation of being able to dump rows I can't
> > normally see.
>
> That's true.  But I should also have an expectation that running
> pg_dump won't trigger arbitrary code execution, which is why by
> default, pg_dump sets row_security to OFF.  That way, if a row
> security policy applies, I get an error rather than an incomplete,
> possibly-invalid dump (and arbitrary code execution on the server
> side).  If I'm OK with doing the dump subject to row security, I can
> rerun with --enable-row-security.  But this proposal would force
> non-superusers to always use that option, and that's not a good idea.
Arbitrary code execution is quite a different concern from the prior
concern regarding incomplete dumps.

To the extent that untrusted code execution is an issue (and my
experience with environments which would deploy RLS tells me that it
isn't a practical concern), an option could be created which would cause
an error to be thrown on non-catalog RLS being run.

When it comes to multi-tenancy environments, as this thread is about,
chances are the only tables you can see are ones which you own or are
owned by a trusted user, which is why I don't view this as a pratical
concern, but I'm not against having a solution to address the issue
raised regarding arbitrary code execution, provided it doesn't create
more problems than it purports to solve.

Thanks!

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Stephen Frost
In reply to this post by Joshua D. Drake
JD,

* Joshua D. Drake ([hidden email]) wrote:
> pg_dump -U $non-super_user
>
> Should just work, period.

That ship has sailed already, where you're running a pg_dump against
objects you don't own and which have RLS enabled on them.

Thanks!

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Robert Haas
In reply to this post by Stephen Frost
On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost <[hidden email]> wrote:
> Arbitrary code execution is quite a different concern from the prior
> concern regarding incomplete dumps.

I've had both concerns all along, and I think I've mentioned them before.

> To the extent that untrusted code execution is an issue (and my
> experience with environments which would deploy RLS tells me that it
> isn't a practical concern), an option could be created which would cause
> an error to be thrown on non-catalog RLS being run.

There's a major release already in the wild that doesn't behave that
way.  And anyway I think that's missing the point: it's true that
features that are turned off don't cause problems, but features that
are turned on shouldn't break things either.

> When it comes to multi-tenancy environments, as this thread is about,
> chances are the only tables you can see are ones which you own or are
> owned by a trusted user, which is why I don't view this as a pratical
> concern, but I'm not against having a solution to address the issue
> raised regarding arbitrary code execution, provided it doesn't create
> more problems than it purports to solve.

Well, I'm against accepting this patch without such a solution.

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


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Robert Haas
In reply to this post by Stephen Frost
On Tue, Feb 9, 2016 at 3:28 PM, Stephen Frost <[hidden email]> wrote:
> JD,
>
> * Joshua D. Drake ([hidden email]) wrote:
>> pg_dump -U $non-super_user
>>
>> Should just work, period.
>
> That ship has sailed already, where you're running a pg_dump against
> objects you don't own and which have RLS enabled on them.

But you'll get an error rather than an incomplete dump, and you won't
run some code that you didn't want to run.  Those distinctions matter.

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


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Stephen Frost
In reply to this post by Robert Haas
* Robert Haas ([hidden email]) wrote:
> On Tue, Feb 9, 2016 at 3:26 PM, Stephen Frost <[hidden email]> wrote:
> > To the extent that untrusted code execution is an issue (and my
> > experience with environments which would deploy RLS tells me that it
> > isn't a practical concern), an option could be created which would cause
> > an error to be thrown on non-catalog RLS being run.
>
> There's a major release already in the wild that doesn't behave that
> way.

I'm at a loss as to what you're getting at there.  We don't have any
catalog RLS, and when it comes to non-catalog RLS, we do have an option
to throw an error when it's going to be run (and it's the default, as
you pointed out), in the one major version which supports RLS.

> And anyway I think that's missing the point: it's true that
> features that are turned off don't cause problems, but features that
> are turned on shouldn't break things either.

I don't, generally, disagree with that statement, but we have to agree
on what's on vs. off and what is broken vs. working correctly.  See
nearby comments from JD about how non-superuser pg_dump could be seen as
broken when running against an environment where RLS is in use.

> > When it comes to multi-tenancy environments, as this thread is about,
> > chances are the only tables you can see are ones which you own or are
> > owned by a trusted user, which is why I don't view this as a pratical
> > concern, but I'm not against having a solution to address the issue
> > raised regarding arbitrary code execution, provided it doesn't create
> > more problems than it purports to solve.
>
> Well, I'm against accepting this patch without such a solution.

That's at least something which can be built upon then to help this
progress.

Thanks!

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Joshua D. Drake
In reply to this post by Stephen Frost
On 02/09/2016 12:28 PM, Stephen Frost wrote:
> JD,
>
> * Joshua D. Drake ([hidden email]) wrote:
>> pg_dump -U $non-super_user
>>
>> Should just work, period.
>
> That ship has sailed already, where you're running a pg_dump against
> objects you don't own and which have RLS enabled on them.

Just to be clear, what I was suggesting is that pg_dump would just work
(and RLS would properly execute) or in other words, I shouldn't have to
tell pg_dump to enable row security else throw an error. If RLS is
enabled, then the backup just runs with appropriate permissions.

Or am I missing something?

Sincerely,

JD


>
> Thanks!
>
> Stephen
>


--
Command Prompt, Inc.                  http://the.postgres.company/
                         +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Stephen Frost
JD,

* Joshua D. Drake ([hidden email]) wrote:

> On 02/09/2016 12:28 PM, Stephen Frost wrote:
> >* Joshua D. Drake ([hidden email]) wrote:
> >>pg_dump -U $non-super_user
> >>
> >>Should just work, period.
> >
> >That ship has sailed already, where you're running a pg_dump against
> >objects you don't own and which have RLS enabled on them.
>
> Just to be clear, what I was suggesting is that pg_dump would just
> work (and RLS would properly execute) or in other words, I shouldn't
> have to tell pg_dump to enable row security else throw an error. If
> RLS is enabled, then the backup just runs with appropriate
> permissions.
>
> Or am I missing something?
You do have to tell pg_dump to enable RLS if you want it to be enabled
when performing a pg_dump.  There's multiple reasons for this, the first
being that, otherwise, you might get an incomplete dump, and secondly,
you might execute a function that some untrusted user wrote and included
in their RLS policy.  We want to avoid both of those, unless you've
specifically asked for it to be done.  That's why row_security is set to
'off' by pg_dump by default.

Thanks!

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Dean Rasheed-3
In reply to this post by Robert Haas
On 9 February 2016 at 19:47, Robert Haas <[hidden email]> wrote:

> I think you're dismissing Tom's concerns far too lightly.  The
> row_security=off mode, which is the default, becomes unusable for
> non-superusers under this proposal.  That's bad.  And if you switch to
> the other mode, then you might accidentally fail to get all of the
> data in some table you're trying to back up.  That's bad too: that's
> why it isn't the default.  There's a big difference between saying
> "I'm OK with not dumping the tables I can't see" and "I'm OK with not
> dumping all of the data in some table I *can* see".
>
> It seems to me that there's a big difference between policies we ship
> out of the box and policies that are created be users: specifically,
> the former can be assumed benign, while the latter can't.  I think
> that difference matters here, although I'm not sure exactly where to
> go with it.
>

It sounds like there needs to be a separate system_row_security
setting that controls RLS on the system catalogs, and that it should
be on by default in pg_dump.

Regards,
Dean


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Joe Conway
In reply to this post by Robert Haas
On 02/09/2016 12:47 PM, Robert Haas wrote:

> On Tue, Feb 9, 2016 at 3:28 PM, Stephen Frost <[hidden email]> wrote:
>> JD,
>>
>> * Joshua D. Drake ([hidden email]) wrote:
>>> pg_dump -U $non-super_user
>>>
>>> Should just work, period.
>>
>> That ship has sailed already, where you're running a pg_dump against
>> objects you don't own and which have RLS enabled on them.
>
> But you'll get an error rather than an incomplete dump, and you won't
> run some code that you didn't want to run.  Those distinctions matter.
From the perspective of that unprivileged user, the dump is not
incomplete -- it is exactly as complete as it is supposed to be.

Personally I don't buy that the current situation is a good thing. I
know that the "ship has sailed" and regret not having participated in
the earlier discussions, but I agree with JD here -- the unprivileged
user should not have to even think about whether RLS exists, they should
only see what they have been allowed to see by the privileged users (and
in the context of their own objects, owners are privileged). I don't
think an unprivileged user should get to decide what code runs in order
to make that happen.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Stephen Frost
In reply to this post by Dean Rasheed-3
* Dean Rasheed ([hidden email]) wrote:

> On 9 February 2016 at 19:47, Robert Haas <[hidden email]> wrote:
> > I think you're dismissing Tom's concerns far too lightly.  The
> > row_security=off mode, which is the default, becomes unusable for
> > non-superusers under this proposal.  That's bad.  And if you switch to
> > the other mode, then you might accidentally fail to get all of the
> > data in some table you're trying to back up.  That's bad too: that's
> > why it isn't the default.  There's a big difference between saying
> > "I'm OK with not dumping the tables I can't see" and "I'm OK with not
> > dumping all of the data in some table I *can* see".
> >
> > It seems to me that there's a big difference between policies we ship
> > out of the box and policies that are created be users: specifically,
> > the former can be assumed benign, while the latter can't.  I think
> > that difference matters here, although I'm not sure exactly where to
> > go with it.
>
> It sounds like there needs to be a separate system_row_security
> setting that controls RLS on the system catalogs, and that it should
> be on by default in pg_dump.
Right, that's what I had been thinking also.

Thanks (and congrats, btw!),

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Tom Lane-2
In reply to this post by Joe Conway
Joe Conway <[hidden email]> writes:
> Personally I don't buy that the current situation is a good thing. I
> know that the "ship has sailed" and regret not having participated in
> the earlier discussions, but I agree with JD here -- the unprivileged
> user should not have to even think about whether RLS exists, they should
> only see what they have been allowed to see by the privileged users (and
> in the context of their own objects, owners are privileged). I don't
> think an unprivileged user should get to decide what code runs in order
> to make that happen.

Part of the problem here is that we have *not* created any hard and fast
distinction between "privileged" and "unprivileged" users; I think that
even speaking in those terms about RLS risks errors in your thinking.

In particular, the code-execution issue arises from the fact that a table
owner can now cause code to execute *with the permissions of someone else*
if the someone else is foolish enough to select from his table.  No
special privileges required, just the ability to create a table.  If we
make pg_dump run with RLS enabled, then the "foolish" part doesn't need to
be any more foolish than forgetting a -t switch when using pg_dump.

Maybe we need to restrict that somehow, or maybe some better solution
exists that we've not thought of yet.  But in its current state, RLS
is at least as much a security hazard as it is a security aid.
I do not want to see it extended in ways that make pg_dump unsafe to
use.

                        regards, tom lane


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Stephen Frost
Tom,

* Tom Lane ([hidden email]) wrote:

> Joe Conway <[hidden email]> writes:
> > Personally I don't buy that the current situation is a good thing. I
> > know that the "ship has sailed" and regret not having participated in
> > the earlier discussions, but I agree with JD here -- the unprivileged
> > user should not have to even think about whether RLS exists, they should
> > only see what they have been allowed to see by the privileged users (and
> > in the context of their own objects, owners are privileged). I don't
> > think an unprivileged user should get to decide what code runs in order
> > to make that happen.
>
> Part of the problem here is that we have *not* created any hard and fast
> distinction between "privileged" and "unprivileged" users; I think that
> even speaking in those terms about RLS risks errors in your thinking.
I agree that where, exactly, that line is drawn is part of the issue,
and where's it's drawn is really system-dependent.  In many
environments, I view Joe's comments as entirely accurate- only
privileged users are allowed to create objects *at all*.  Of course,
there are a lot of environments where everyone is allowed to create
objects and, in those environments, all those users would be viewed as
"unprivileged", generally speaking.

> In particular, the code-execution issue arises from the fact that a table
> owner can now cause code to execute *with the permissions of someone else*
> if the someone else is foolish enough to select from his table.  No
> special privileges required, just the ability to create a table.  If we
> make pg_dump run with RLS enabled, then the "foolish" part doesn't need to
> be any more foolish than forgetting a -t switch when using pg_dump.

That distinction is really only relevant when it comes to pg_dump, as
those same users could use views to cause their code to be executed by
other users who are selecting from their view, and they could change if
it's a table or a view quite easily.  From a practical standpoint, we're
making a huge distinction between our client tools- pg_dump must be
protected from X, but we don't have any such qualms or concerns
regarding queries sent from psql.

Perhaps that's the right distinction to make, or perhaps we should come
up with a better answer for psql than what we have now, but I don't
agree that RLS is seriously moving the goalposts, overall, here,
particularly since you're not going to have any RLS policies being
executed by pg_dump when run as a superuser anyway, given Noah's change
to how BYPASSRLS works.

> Maybe we need to restrict that somehow, or maybe some better solution
> exists that we've not thought of yet.  But in its current state, RLS
> is at least as much a security hazard as it is a security aid.
> I do not want to see it extended in ways that make pg_dump unsafe to
> use.

I'm not against coming up with an approach which restricts cases where
user A can write code that will be run under another user's rights,
provided it doesn't make the system overly painful to use.  I don't see
RLS as changing the security risks all that much when you're talking
about regular user queries through psql, and the concern regarding
pg_dump has been addressed through the default of row_security being
off.

Thanks!

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Joe Conway
In reply to this post by Tom Lane-2
On 02/09/2016 01:22 PM, Tom Lane wrote:
> Maybe we need to restrict that somehow, or maybe some better solution
> exists that we've not thought of yet.  But in its current state, RLS
> is at least as much a security hazard as it is a security aid.
> I do not want to see it extended in ways that make pg_dump unsafe to
> use.

Ok, I can see that. Maybe we should have a specific GRANT for CREATE
POLICY which is distinct from the privilege to CREATE TABLE?

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Stephen Frost
* Joe Conway ([hidden email]) wrote:
> On 02/09/2016 01:22 PM, Tom Lane wrote:
> > Maybe we need to restrict that somehow, or maybe some better solution
> > exists that we've not thought of yet.  But in its current state, RLS
> > is at least as much a security hazard as it is a security aid.
> > I do not want to see it extended in ways that make pg_dump unsafe to
> > use.
>
> Ok, I can see that. Maybe we should have a specific GRANT for CREATE
> POLICY which is distinct from the privilege to CREATE TABLE?

Well, the only privilege we have now is "CREATE", which allows creation
of any kind of object inside a schema.  I'm generally in favor of
providing more granluar 'create table', 'create view', etc privileges
that can be granted out at the schema level, and 'create policy' would
be appropriate to include in such a set of object-creation permissions.

I don't have any particularly genius ideas about where we'd get the bits
to implement such a grant system though.  We could modify the existing
grant system to use larger bits, but given that this would only be
applicable for schemas, perhaps it'd make sense to have another field
in pg_namespace instead?  Not sure, just brainstorming here.

Thanks!

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Robert Haas
In reply to this post by Tom Lane-2
On Tue, Feb 9, 2016 at 4:22 PM, Tom Lane <[hidden email]> wrote:
> Part of the problem here is that we have *not* created any hard and fast
> distinction between "privileged" and "unprivileged" users; I think that
> even speaking in those terms about RLS risks errors in your thinking.

+1.

> In particular, the code-execution issue arises from the fact that a table
> owner can now cause code to execute *with the permissions of someone else*
> if the someone else is foolish enough to select from his table.  No
> special privileges required, just the ability to create a table.  If we
> make pg_dump run with RLS enabled, then the "foolish" part doesn't need to
> be any more foolish than forgetting a -t switch when using pg_dump.

Yes.  That is exactly why I argued for the current situation to be the
way it is, and I think it would have been a huge mistake if we now
decided otherwise.  I don't have a ton of confidence that the database
is free of problems that would allow one user to assume the privileges
of another - but I certainly don't want to design more such problems
into the server.

> Maybe we need to restrict that somehow, or maybe some better solution
> exists that we've not thought of yet.  But in its current state, RLS
> is at least as much a security hazard as it is a security aid.
> I do not want to see it extended in ways that make pg_dump unsafe to
> use.

I could not agree more.

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


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multi-tenancy with RLS

Haribabu Kommi-2
Hi All,

Here I attached new set of patches related to supporting of multi tenancy.
All the existing old patches are just rebased to latest master.

A new patch is added to address the pg_dump problem of dumping the data
based on the visibility after applying catalog row level security policies.

A new GUC catalog_row_level_security option is added, this option is
ON by default
and it will be set to OFF by pg_dump whenever --disable-catalog-row-security is
passed as an option to pg_dump. I didn't add this option to pg_restore similar
like --enable-row-security as I don't find a need for the same. By
default pg_dump
dumps the data that is visible to the user, whenever the catalog_row_security is
disabled and there exists some row level security policies, an error
is thrown similar
like row_security.

The above changes are based on my understanding to the discussion occurred in
this mail. In case if I miss anything, please let me know, i will
correct the same.

Regards,
Hari Babu
Fujitsu Australia


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

5_pgdump_new_row_security_option_v1.patch (10K) Download Attachment
1_any_privilege_option_v1.patch (7K) Download Attachment
2_view_security_definer_v1.patch (17K) Download Attachment
3_shared_catalog_tenancy_v1.patch (28K) Download Attachment
4_database_catalog_tenancy_v1.patch (127K) Download Attachment
1234
Previous Thread Next Thread
Loading...