Data Packaging/Data Unpacking

Started by oleg yusimabout 10 years ago11 messagesgeneral
Jump to latest
#1oleg yusim
olegyusim@gmail.com

Greetings,

I have matching couple of security requirements, speaking about preserving
data confidentiality and integrity in PostgreSQL DB during packaging for
transmission / unpacking from transmission.

Important: let's assume data at rest is encrypted using EFS and data at
transit is encrypted using ciphers, provided by OpenSSL.

So, with that in mind, please, help me to understand movement and location
of the data between the moment when it is pulled from file system and
encrypted as network package going through the SSL tunnel.

And reversing it - between the moment network package arrived through the
SSL tunnel is decrypted and the moment its content is placed into the file
system.

For those interested, here are requirements themselves, quoted:

1) The DBMS must maintain the confidentiality and integrity of information
during preparation for transmission.

Information can be either unintentionally or maliciously disclosed or
modified during preparation for transmission, including, for example,
during aggregation, at protocol transformation points, and during
packing/unpacking. These unauthorized disclosures or modifications
compromise the confidentiality or integrity of the information.

Use of this requirement will be limited to situations where the data owner
has a strict requirement for ensuring data integrity and confidentiality is
maintained at every step of the data transfer and handling process.

When transmitting data, the DBMS, associated applications, and
infrastructure must leverage transmission protection mechanisms.

2) The DBMS must maintain the confidentiality and integrity of information
during reception.

Information can be either unintentionally or maliciously disclosed or
modified during reception, including, for example, during aggregation, at
protocol transformation points, and during packing/unpacking. These
unauthorized disclosures or modifications compromise the confidentiality or
integrity of the information.

This requirement applies only to those applications that are either
distributed or can allow access to data non-locally. Use of this
requirement will be limited to situations where the data owner has a strict
requirement for ensuring data integrity and confidentiality is maintained
at every step of the data transfer and handling process.

When receiving data, the DBMS, associated applications, and infrastructure
must leverage protection mechanisms.

Thanks,

Oleg

#2oleg yusim
olegyusim@gmail.com
In reply to: oleg yusim (#1)
Fwd: Data Packaging/Data Unpacking

Appologies, for posting it again, but I didn't get any responses so far.
Looks like I posted it too late in the evening and it went not noticed.

Oleg

---------- Forwarded message ----------
From: oleg yusim <olegyusim@gmail.com>
Date: Tue, Jan 12, 2016 at 10:00 PM
Subject: Data Packaging/Data Unpacking
To: PostgreSQL General <pgsql-general@postgresql.org>

Greetings,

I have matching couple of security requirements, speaking about preserving
data confidentiality and integrity in PostgreSQL DB during packaging for
transmission / unpacking from transmission.

Important: let's assume data at rest is encrypted using EFS and data at
transit is encrypted using ciphers, provided by OpenSSL.

So, with that in mind, please, help me to understand movement and location
of the data between the moment when it is pulled from file system and
encrypted as network package going through the SSL tunnel.

And reversing it - between the moment network package arrived through the
SSL tunnel is decrypted and the moment its content is placed into the file
system.

For those interested, here are requirements themselves, quoted:

1) The DBMS must maintain the confidentiality and integrity of information
during preparation for transmission.

Information can be either unintentionally or maliciously disclosed or
modified during preparation for transmission, including, for example,
during aggregation, at protocol transformation points, and during
packing/unpacking. These unauthorized disclosures or modifications
compromise the confidentiality or integrity of the information.

Use of this requirement will be limited to situations where the data owner
has a strict requirement for ensuring data integrity and confidentiality is
maintained at every step of the data transfer and handling process.

When transmitting data, the DBMS, associated applications, and
infrastructure must leverage transmission protection mechanisms.

2) The DBMS must maintain the confidentiality and integrity of information
during reception.

Information can be either unintentionally or maliciously disclosed or
modified during reception, including, for example, during aggregation, at
protocol transformation points, and during packing/unpacking. These
unauthorized disclosures or modifications compromise the confidentiality or
integrity of the information.

This requirement applies only to those applications that are either
distributed or can allow access to data non-locally. Use of this
requirement will be limited to situations where the data owner has a strict
requirement for ensuring data integrity and confidentiality is maintained
at every step of the data transfer and handling process.

When receiving data, the DBMS, associated applications, and infrastructure
must leverage protection mechanisms.

Thanks,

Oleg

#3Kevin Grittner
Kevin.Grittner@wicourts.gov
In reply to: oleg yusim (#1)
Re: Data Packaging/Data Unpacking

On Tue, Jan 12, 2016 at 10:00 PM, oleg yusim <olegyusim@gmail.com> wrote:

Important: let's assume data at rest is encrypted using EFS and data at
transit is encrypted using ciphers, provided by OpenSSL.

So, with that in mind, please, help me to understand movement and location
of the data between the moment when it is pulled from file system and
encrypted as network package going through the SSL tunnel.

And reversing it - between the moment network package arrived through the
SSL tunnel is decrypted and the moment its content is placed into the file
system.

At all times the data is present only in files owned by the OS user
which runs the database server or in RAM allocated to processes run
by that user. Files and RAM are freed without overwrite; we count
on the OS to not gratuitously show the old values to processes
making new allocations.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

#4oleg yusim
olegyusim@gmail.com
In reply to: Kevin Grittner (#3)
Re: Data Packaging/Data Unpacking

Kevin,

Thank you for your reply. I understand what you are saying, but I guess I
need a bit deeper understanding for my assessment. Let's dive a bit here:

Say, I got network package. The package was decrypted by OpenSSL. Where
this data are, physically, at this moment?

Opposite situation: we are about to send results of SELECT statement over
the OpenSSL tunnel. Where are the data, physically, between the moment DB
engine returned results for my query and moment the package was encrypted
by OpenSSL?

Thanks,

Oleg

On Wed, Jan 13, 2016 at 2:46 PM, Kevin Grittner <kgrittn@gmail.com> wrote:

Show quoted text

On Tue, Jan 12, 2016 at 10:00 PM, oleg yusim <olegyusim@gmail.com> wrote:

Important: let's assume data at rest is encrypted using EFS and data at
transit is encrypted using ciphers, provided by OpenSSL.

So, with that in mind, please, help me to understand movement and

location

of the data between the moment when it is pulled from file system and
encrypted as network package going through the SSL tunnel.

And reversing it - between the moment network package arrived through the
SSL tunnel is decrypted and the moment its content is placed into the

file

system.

At all times the data is present only in files owned by the OS user
which runs the database server or in RAM allocated to processes run
by that user. Files and RAM are freed without overwrite; we count
on the OS to not gratuitously show the old values to processes
making new allocations.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

#5Kevin Grittner
Kevin.Grittner@wicourts.gov
In reply to: oleg yusim (#4)
Re: Data Packaging/Data Unpacking

On Wed, Jan 13, 2016 at 2:57 PM, oleg yusim <olegyusim@gmail.com> wrote:

Say, I got network package. The package was decrypted by OpenSSL. Where this
data are, physically, at this moment?

Process-local memory for the PostgreSQL backend process associated
with the database connection.

Opposite situation: we are about to send results of SELECT statement over
the OpenSSL tunnel. Where are the data, physically, between the moment DB
engine returned results for my query and moment the package was encrypted by
OpenSSL?

Process-local memory for the PostgreSQL backend process associated
with the database connection.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

#6David G. Johnston
david.g.johnston@gmail.com
In reply to: Kevin Grittner (#5)
Re: Data Packaging/Data Unpacking

On Wed, Jan 13, 2016 at 2:19 PM, Kevin Grittner <kgrittn@gmail.com> wrote:

On Wed, Jan 13, 2016 at 2:57 PM, oleg yusim <olegyusim@gmail.com> wrote:

Say, I got network package. The package was decrypted by OpenSSL. Where

this

data are, physically, at this moment?

Process-local memory for the PostgreSQL backend process associated
with the database connection.

Opposite situation: we are about to send results of SELECT statement over
the OpenSSL tunnel. Where are the data, physically, between the moment DB
engine returned results for my query and moment the package was

encrypted by

OpenSSL?

Process-local memory for the PostgreSQL backend process associated
with the database connection.

​In other words (?) while OpenSSL may be a separate project the method of
its use involves loading all relevant code into the process space​

​of PostgreSQL - specifically the process that was forked when the SSL
client connection was established.

David J.​

#7oleg yusim
olegyusim@gmail.com
In reply to: David G. Johnston (#6)
Re: Data Packaging/Data Unpacking

OK, Kevin, David,

Thanks you very much for explanation. Now who is the owner of this process?
My understanding is, data then located physically in RAM, in the memory
stack assigned by OS to this process. Now the question is who owns the
process?

Thanks,

Oleg

On Wed, Jan 13, 2016 at 3:29 PM, David G. Johnston <
david.g.johnston@gmail.com> wrote:

Show quoted text

On Wed, Jan 13, 2016 at 2:19 PM, Kevin Grittner <kgrittn@gmail.com> wrote:

On Wed, Jan 13, 2016 at 2:57 PM, oleg yusim <olegyusim@gmail.com> wrote:

Say, I got network package. The package was decrypted by OpenSSL. Where

this

data are, physically, at this moment?

Process-local memory for the PostgreSQL backend process associated
with the database connection.

Opposite situation: we are about to send results of SELECT statement

over

the OpenSSL tunnel. Where are the data, physically, between the moment

DB

engine returned results for my query and moment the package was

encrypted by

OpenSSL?

Process-local memory for the PostgreSQL backend process associated
with the database connection.

​In other words (?) while OpenSSL may be a separate project the method of
its use involves loading all relevant code into the process space​

​of PostgreSQL - specifically the process that was forked when the SSL
client connection was established.

David J.​

#8David G. Johnston
david.g.johnston@gmail.com
In reply to: oleg yusim (#7)
Re: Data Packaging/Data Unpacking

On Wed, Jan 13, 2016 at 2:37 PM, oleg yusim <olegyusim@gmail.com> wrote:

OK, Kevin, David,

Thanks you very much for explanation. Now who is the owner of this
process? My understanding is, data then located physically in RAM, in the
memory stack assigned by OS to this process. Now the question is who owns
the process?

Who owns the PostgreSQL backend user process?​

​Typically the ​"postgres" user.
Who owns the "process" responsible for marshalling data back and forth from
RAM? There isn't really a concept of "process" when dealing with system
resources. The kernel is responsible for management of those resources.
Processes are a user-space concern.

There may be some here concerned with the deep workings of the various O/S
that PostgreSQL runs on but ultimately the answer, from PostgreSQL's
perspective, is that we use system APIs to request and use resources and
expect the underlying system to handle those securely. If you want to know
how that layer works you should ask there since it seems out-of-scope for
this forum.

David J.

#9oleg yusim
olegyusim@gmail.com
In reply to: David G. Johnston (#8)
Re: Data Packaging/Data Unpacking

David,

Answer "postgres" would suffice. I have fairly decent idea of what happens
below that (you are right system utility - Memory Manager is what
marshaling data back and forth to RAM, abstracting absolute addresses from
application along the way, and once in RAM, security kernel of the system
protects data, terminating any process which tries to obtain data from
another process - provided data were not shared to begin with).

Thanks a lot for your consultation guys.

Oleg

On Wed, Jan 13, 2016 at 3:49 PM, David G. Johnston <
david.g.johnston@gmail.com> wrote:

Show quoted text

On Wed, Jan 13, 2016 at 2:37 PM, oleg yusim <olegyusim@gmail.com> wrote:

OK, Kevin, David,

Thanks you very much for explanation. Now who is the owner of this
process? My understanding is, data then located physically in RAM, in the
memory stack assigned by OS to this process. Now the question is who owns
the process?

Who owns the PostgreSQL backend user process?​

​Typically the ​"postgres" user.
Who owns the "process" responsible for marshalling data back and forth
from RAM? There isn't really a concept of "process" when dealing with
system resources. The kernel is responsible for management of those
resources. Processes are a user-space concern.

There may be some here concerned with the deep workings of the various O/S
that PostgreSQL runs on but ultimately the answer, from PostgreSQL's
perspective, is that we use system APIs to request and use resources and
expect the underlying system to handle those securely. If you want to know
how that layer works you should ask there since it seems out-of-scope for
this forum.

David J.

#10Kevin Grittner
Kevin.Grittner@wicourts.gov
In reply to: oleg yusim (#9)
Re: Data Packaging/Data Unpacking

On Wed, Jan 13, 2016 at 3:54 PM, oleg yusim <olegyusim@gmail.com> wrote:

Answer "postgres" would suffice.

But the user would not always be "postgres". To be accurate, it is
the user which owns the files for the "cluster" (database instance)
and which runs the database service. If a machine contains
multiple clusters it is (IMO) best practice, for both security and
operational reasons, to use a separate OS user for each cluster.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

#11oleg yusim
olegyusim@gmail.com
In reply to: Kevin Grittner (#10)
Re: Data Packaging/Data Unpacking

Kevin,

It is understood. But doesn't change things from my perspective. It would
anyway be user, with sole access, nobody can elevate privileges to and only
root can su to. The name, in that case, is irrelevant, but answer postgres
gave me idea of the protection level here.

Thanks,

Oleg

On Wed, Jan 13, 2016 at 4:04 PM, Kevin Grittner <kgrittn@gmail.com> wrote:

Show quoted text

On Wed, Jan 13, 2016 at 3:54 PM, oleg yusim <olegyusim@gmail.com> wrote:

Answer "postgres" would suffice.

But the user would not always be "postgres". To be accurate, it is
the user which owns the files for the "cluster" (database instance)
and which runs the database service. If a machine contains
multiple clusters it is (IMO) best practice, for both security and
operational reasons, to use a separate OS user for each cluster.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company