security labels on databases are bad for dump & restore

On Fri, Jul 10, 2015 at 7:57 AM, Andres Freund <andres@anarazel.de> wrote:

pg_dump dumps security labels on databases. Which makes sense. The
problem is that they're dumped including the database name.

Which means that if you dump a database and restore it into a
differently named one you'll either get a failure because the database
does not exist, or worse you'll update the label of the wrong database.

So I think we need CURRENT_DATABASE (or similar) support for security
labels on databases.

I won't have time to do anything about this anytime soon, but I think we
should fix that at some point. Shall I put this on the todo? Or do we
want to create an 'open items' page that's not major version specific?

I think adding it to the TODO would be great.

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

All,

I won't have time to do anything about this anytime soon, but I think we
should fix that at some point. Shall I put this on the todo? Or do we
want to create an 'open items' page that's not major version specific?

I think adding it to the TODO would be great.

I'd be willing to look/dive into this one further.

-Adam

--
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com

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

I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?

Ted

On Tue, Jul 14, 2015 at 12:09 PM, Adam Brightwell
<adam.brightwell@crunchydatasolutions.com> wrote:

All,

I won't have time to do anything about this anytime soon, but I think we
should fix that at some point. Shall I put this on the todo? Or do we
want to create an 'open items' page that's not major version specific?

I think adding it to the TODO would be great.

I'd be willing to look/dive into this one further.

-Adam

--
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com

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

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

On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth <txtoth@gmail.com> wrote:

I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?

See contrib/sepgsql

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

That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.

Ted

On Tue, Jul 14, 2015 at 12:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth <txtoth@gmail.com> wrote:

I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?

See contrib/sepgsql

--
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-07-15 2:39 GMT+09:00 Ted Toth <txtoth@gmail.com>:

That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.

It depends on the definition of "integrated".
The PostgreSQL core offers an infrastructure for label based security
mechanism, not only selinux. Also, one extension module that is
usually distributed with PosgreSQL bridges the world of database and
the world of selinux (even though all the features I initially designed
are not yet implemented). I like to say it is integrated.

On Tue, Jul 14, 2015 at 12:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth <txtoth@gmail.com> wrote:

I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?

See contrib/sepgsql

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

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

So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?

Ted

On Tue, Jul 14, 2015 at 12:53 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2015-07-15 2:39 GMT+09:00 Ted Toth <txtoth@gmail.com>:

That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.

It depends on the definition of "integrated".
The PostgreSQL core offers an infrastructure for label based security
mechanism, not only selinux. Also, one extension module that is
usually distributed with PosgreSQL bridges the world of database and
the world of selinux (even though all the features I initially designed
are not yet implemented). I like to say it is integrated.

On Tue, Jul 14, 2015 at 12:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth <txtoth@gmail.com> wrote:

I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?

See contrib/sepgsql

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

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

So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?

Of course, it depends on the policy of the system.

If client connection come from none-SELinux system, use netlabelctl
to configure default fallback security context. It gives getpeercon(3)
the client label shall be applied when netlabel is not configured on
the connection.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Ted Toth
Sent: Wednesday, July 15, 2015 2:59 AM
To: Kohei KaiGai
Cc: Robert Haas; Adam Brightwell; Andres Freund; pgsql-hackers@postgresql.org;
Alvaro Herrera
Subject: Re: [HACKERS] security labels on databases are bad for dump & restore

So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?

Ted

On Tue, Jul 14, 2015 at 12:53 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2015-07-15 2:39 GMT+09:00 Ted Toth <txtoth@gmail.com>:

That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.

It depends on the definition of "integrated".
The PostgreSQL core offers an infrastructure for label based security
mechanism, not only selinux. Also, one extension module that is
usually distributed with PosgreSQL bridges the world of database and
the world of selinux (even though all the features I initially designed
are not yet implemented). I like to say it is integrated.

On Tue, Jul 14, 2015 at 12:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth <txtoth@gmail.com> wrote:

I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?

See contrib/sepgsql

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

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

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

That doesn't answer my question. I'm talking about a client and server
running on the same system with SELinux MLS policy so that getpeercon
will return the context of the client process unless it has explicitly
sets the socket create context . So again will postgresql if the
sepgsql module is loaded call a function in sepgsql to compute the
access vector for the source (getpeercon label) contexts access to the
target context (tables context set by SECURITY LABEL) and fail the
operation generating an AVC if access is denied because there is no
policy?

On Tue, Jul 14, 2015 at 8:35 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:

So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?

Of course, it depends on the policy of the system.

If client connection come from none-SELinux system, use netlabelctl
to configure default fallback security context. It gives getpeercon(3)
the client label shall be applied when netlabel is not configured on
the connection.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Ted Toth
Sent: Wednesday, July 15, 2015 2:59 AM
To: Kohei KaiGai
Cc: Robert Haas; Adam Brightwell; Andres Freund; pgsql-hackers@postgresql.org;
Alvaro Herrera
Subject: Re: [HACKERS] security labels on databases are bad for dump & restore

So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?

Ted

On Tue, Jul 14, 2015 at 12:53 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2015-07-15 2:39 GMT+09:00 Ted Toth <txtoth@gmail.com>:

That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.

It depends on the definition of "integrated".
The PostgreSQL core offers an infrastructure for label based security
mechanism, not only selinux. Also, one extension module that is
usually distributed with PosgreSQL bridges the world of database and
the world of selinux (even though all the features I initially designed
are not yet implemented). I like to say it is integrated.

On Tue, Jul 14, 2015 at 12:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth <txtoth@gmail.com> wrote:

I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?

See contrib/sepgsql

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

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

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

That doesn't answer my question. I'm talking about a client and server
running on the same system with SELinux MLS policy so that getpeercon
will return the context of the client process unless it has explicitly
sets the socket create context . So again will postgresql if the
sepgsql module is loaded call a function in sepgsql to compute the
access vector for the source (getpeercon label) contexts access to the
target context (tables context set by SECURITY LABEL) and fail the
operation generating an AVC if access is denied because there is no
policy?

Yes. You may see AVC denial/allowed message on PostgreSQL log, like:

LOG: SELinux: allowed { create } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:object_r:sepgsql_table_t:s0 tclass=db_table name="regtest_schema.regtest_table"

scontext comes from getpeercon(3),
tcontext comes from the configuration by SECURITY LABEL command.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>

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

On 2015-07-14 13:09:26 -0400, Adam Brightwell wrote:

All,

I won't have time to do anything about this anytime soon, but I think we
should fix that at some point. Shall I put this on the todo? Or do we
want to create an 'open items' page that's not major version specific?

I think adding it to the TODO would be great.

Done. It's rather telling that it took me a fair while to find a spot in
the todo list where it fits...

I'd be willing to look/dive into this one further.

Cool.

One thing worth mentioning is that arguably the problem is caused by the
fact that we're here emitting database level information in pg_dump,
normally only done for dumpall.

Greetings,

Andres Freund

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

Andres Freund wrote:

One thing worth mentioning is that arguably the problem is caused by the
fact that we're here emitting database level information in pg_dump,
normally only done for dumpall.

... the reason for which is probably the lack of CURRENT_DATABASE as a
database specifier. It might make sense to add the rest of
database-level information to pg_dump output, when we get that.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:

Andres Freund wrote:

One thing worth mentioning is that arguably the problem is caused by the
fact that we're here emitting database level information in pg_dump,
normally only done for dumpall.

... the reason for which is probably the lack of CURRENT_DATABASE as a
database specifier. It might make sense to add the rest of
database-level information to pg_dump output, when we get that.

I'm not sure. I mean, it's not that an odd idea to assign a label to a
database and then restore data into it, and expect the explicitly
assigned label to survive. Not sure if there actually is a good
behaviour either way here :/

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

On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:

On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:

Andres Freund wrote:

One thing worth mentioning is that arguably the problem is caused by the
fact that we're here emitting database level information in pg_dump,
normally only done for dumpall.

Consistency with existing practice would indeed have pg_dump ignore
pg_shseclabel and have pg_dumpall reproduce its entries.

... the reason for which is probably the lack of CURRENT_DATABASE as a
database specifier. It might make sense to add the rest of
database-level information to pg_dump output, when we get that.

I'm not sure. I mean, it's not that an odd idea to assign a label to a
database and then restore data into it, and expect the explicitly
assigned label to survive. Not sure if there actually is a good
behaviour either way here :/

In a greenfield, I would make "pg_dump --create" reproduce pertinent entries
from datacl, pg_db_role_setting, pg_shseclabel and pg_shdescription. I would
make non-creating pg_dump reproduce none of those. Moreover, I would enable
--create by default. Restoring into a user-provided shell database is
specialized compared to reproducing a database from scratch.

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

Consistency with existing practice would indeed have pg_dump ignore
pg_shseclabel and have pg_dumpall reproduce its entries.

I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that also be ignored by pg_dump as well? I'm
specifically thinking of the discussion from the following thread:

/messages/by-id/20150317172459.GM3636@alvh.no-ip.org

If COMMENT is included then why not SECURITY LABEL or others?

In a greenfield, I would make "pg_dump --create" reproduce pertinent entries
from datacl, pg_db_role_setting, pg_shseclabel and pg_shdescription. I would
make non-creating pg_dump reproduce none of those.

I think the bigger question is "Where is the line drawn between
pg_dump and pg_dumpall?". At what point does one tool become the
other?

-Adam

--
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com

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

On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:

Consistency with existing practice would indeed have pg_dump ignore
pg_shseclabel and have pg_dumpall reproduce its entries.

I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that also be ignored by pg_dump as well? I'm
specifically thinking of the discussion from the following thread:

/messages/by-id/20150317172459.GM3636@alvh.no-ip.org

If COMMENT is included then why not SECURITY LABEL or others?

In any given situation, we should indeed restore both pg_database comments and
pg_database security labels, or we should restore neither. Restoring neither
is most consistent with history, but several people like the idea of restoring
both. I won't mind either conclusion.

In a greenfield, I would make "pg_dump --create" reproduce pertinent entries
from datacl, pg_db_role_setting, pg_shseclabel and pg_shdescription. I would
make non-creating pg_dump reproduce none of those.

I think the bigger question is "Where is the line drawn between
pg_dump and pg_dumpall?". At what point does one tool become the
other?

That question may be too big for me.

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

Noah Misch wrote:

On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:

I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that also be ignored by pg_dump as well? I'm
specifically thinking of the discussion from the following thread:

/messages/by-id/20150317172459.GM3636@alvh.no-ip.org

If COMMENT is included then why not SECURITY LABEL or others?

In any given situation, we should indeed restore both pg_database comments and
pg_database security labels, or we should restore neither.

Agreed.

In a greenfield, I would make "pg_dump --create" reproduce pertinent entries
from datacl, pg_db_role_setting, pg_shseclabel and pg_shdescription. I would
make non-creating pg_dump reproduce none of those.

I think the bigger question is "Where is the line drawn between
pg_dump and pg_dumpall?". At what point does one tool become the
other?

That question may be too big for me.

I don't think there's any line near pg_dumpall. That tool seems to
have grown out of desperation without much actual design. I think it
makes more sense to plan around that's the best pg_dump behavior for the
various use cases.

I like Noah's proposal of having pg_dump --create reproduce all
database-level state.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

I don't think there's any line near pg_dumpall. That tool seems to
have grown out of desperation without much actual design. I think it
makes more sense to plan around that's the best pg_dump behavior for the
various use cases.

Ok.

I like Noah's proposal of having pg_dump --create reproduce all
database-level state.

Should it be enabled by default? If so, then wouldn't it make more
sense to call it --no-create and do the opposite? So, --no-create
would exclude rather than include database-level information? Would
enabling it by default cause issues with the current expected use of
the tool by end users?

How would this handle related global objects? It seems like this part
could get a little tricky.

Taking it one step further, would a --all option that dumps all
databases make sense as well? Of course I know that's probably a
considerable undertaking and certainly beyond the current scope.
Though, I thought I'd throw it out there.

Also, I think this would potentially conflict with what Fabrízio is
doing with CURRENT_DATABASE on COMMENT, though, I think it might be a
preferable solution.

https://commitfest.postgresql.org/5/229/

-Adam

--
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com

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

On Wed, Jul 22, 2015 at 4:42 PM, Adam Brightwell <
adam.brightwell@crunchydatasolutions.com> wrote:

[...]

Also, I think this would potentially conflict with what Fabrízio is
doing with CURRENT_DATABASE on COMMENT, though, I think it might be a
preferable solution.

https://commitfest.postgresql.org/5/229/

Unfortunately this code is a bit weird and will be better to move to the
next commitfest (I have no time to improve it yet), so we can join efforts
and implement all ideas and make the reviewers life easier with a more
consistency patch.

Seems reasonable?

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL