Re: [GENERAL] Failing to known state

[oleg yusim]

Hi Adrian,

Thank you very much for that link. It confirms what JD and John said, plus
explains couple other moments to me.

Thanks,

Oleg

On Tue, Jan 5, 2016 at 7:04 PM, Adrian Klaver 
wrote:

> On 01/05/2016 04:12 PM, oleg yusim wrote:
> > Hi Adrian,
> >
> > I meant a scenario, when user is trying to connect to database (doesn't
> > matter what interface) and database fails at this moment. If all
> > authentication/authorization/validation functions are written to return
> > false in case of abnormal termination, we are fine. If not, we can
> > potentially encounter the situation when database fails into state where
> > user is given greater privileges than he/she should or even
> > authenticated, when he/she shouldn't.
>
> Might want to take a look at:
>
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/postmaster/postmaster.c;h=41dbdf4bf9eeb54ae0a774ab21fc1c1362aa55f9;hb=d25c7d70ff46d1b2f2400f29d100190efe84d70d
>
> /*
>  * CleanupBackend -- cleanup after terminated backend.
>  *
>  * Remove all local state associated with backend.
>  *
>  * If you change this, see also CleanupBackgroundWorker.
>  */
> static void
> CleanupBackend
>
>
> /*
>  * HandleChildCrash -- cleanup after failed backend, bgwriter,
> checkpointer,
>  * walwriter, autovacuum, or background worker.
>  *
>  * The objectives here are to clean up our local state about the child
>  * process, and to signal all other remaining children to quickdie.
>  */
> static void
> HandleChildCrash(in
>
> etc
>
> Just do a find on crash.
>
>
> >
> > Thanks,
> >
> > Oleg
> >
>
>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

Re: [GENERAL] Failing to known state

[oleg yusim]

Hi Joe,

Exactly how I marked it :)

Thanks,

Oleg

On Tue, Jan 5, 2016 at 6:50 PM, Joe Conway  wrote:

> On 01/05/2016 04:32 PM, John R Pierce wrote:
> > On 1/5/2016 4:12 PM, oleg yusim wrote:
> >> I meant a scenario, when user is trying to connect to database
> >> (doesn't matter what interface) and database fails at this moment. If
> >> all authentication/authorization/validation functions are written to
> >> return false in case of abnormal termination, we are fine. If not, we
> >> can potentially encounter the situation when database fails into state
> >> where user is given greater privileges than he/she should or even
> >> authenticated, when he/she shouldn't.
> >
> > if the postgres server processes terminate for any reason, there's
> > nothing to connect to.  the client application will get a error like
> > 'connection refused' back from the connection attempt, or if it was
> > already connected and the server aborts, the next query will return an
> > error like CONNECTION_BAD.  there's no possible privilege elevation.
>
> +1
>
> I think you can call this one "Applicable -- Inherently Meets"
>
> Joe
>
> --
> Crunchy Data - http://crunchydata.com
> PostgreSQL Support for Secure Enterprises
> Consulting, Training, & Open Source Development
>
>

Re: [GENERAL] Failing to known state

[Adrian Klaver]

On 01/05/2016 04:12 PM, oleg yusim wrote:
> Hi Adrian,
> 
> I meant a scenario, when user is trying to connect to database (doesn't 
> matter what interface) and database fails at this moment. If all 
> authentication/authorization/validation functions are written to return 
> false in case of abnormal termination, we are fine. If not, we can 
> potentially encounter the situation when database fails into state where 
> user is given greater privileges than he/she should or even 
> authenticated, when he/she shouldn't.

Might want to take a look at:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/postmaster/postmaster.c;h=41dbdf4bf9eeb54ae0a774ab21fc1c1362aa55f9;hb=d25c7d70ff46d1b2f2400f29d100190efe84d70d

/*
 * CleanupBackend -- cleanup after terminated backend.
 *
 * Remove all local state associated with backend.
 *
 * If you change this, see also CleanupBackgroundWorker.
 */
static void
CleanupBackend


/*
 * HandleChildCrash -- cleanup after failed backend, bgwriter, checkpointer,
 * walwriter, autovacuum, or background worker.
 *
 * The objectives here are to clean up our local state about the child
 * process, and to signal all other remaining children to quickdie.
 */
static void
HandleChildCrash(in

etc

Just do a find on crash.


> 
> Thanks,
> 
> Oleg
> 



-- 
Adrian Klaver
adrian.kla...@aklaver.com


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

Re: [GENERAL] Failing to known state

[oleg yusim]

John,

Thanks, what you are saying makes sense. I agree, it would cause all user
to go through authentication/authorization loop all over and terminate all
running transactions too.

Thanks,

Oleg

On Tue, Jan 5, 2016 at 6:32 PM, John R Pierce  wrote:

> On 1/5/2016 4:12 PM, oleg yusim wrote:
>
> I meant a scenario, when user is trying to connect to database (doesn't
> matter what interface) and database fails at this moment. If all
> authentication/authorization/validation functions are written to return
> false in case of abnormal termination, we are fine. If not, we can
> potentially encounter the situation when database fails into state where
> user is given greater privileges than he/she should or even authenticated,
> when he/she shouldn't.
>
>
>
>
>
> if the postgres server processes terminate for any reason, there's nothing
> to connect to.  the client application will get a error like
> 'connection refused' back from the connection attempt, or if it was already
> connected and the server aborts, the next query will return an error like
> CONNECTION_BAD.  there's no possible privilege elevation.
>
>
>
>
>
> --
> john r pierce, recycling bits in santa cruz
>
>

Re: [GENERAL] Failing to known state

[oleg yusim]

Thanks JD.

Let me confirm I got you right. So, by exception you mean the
authentication/authorization/validation functions would return false in
case of DB failure?

Thanks,

Oleg


On Tue, Jan 5, 2016 at 5:33 PM, Joshua D. Drake 
wrote:

> On 01/05/2016 03:21 PM, oleg yusim wrote:
>
>> Thanks JD.
>>
>>  From what I read about WAL (you have been referring to this:
>> http://www.postgresql.org/docs/current/static/wal-internals.html
>> pg_xlog, right?) it allows us to know what happened, but does it
>> warranty known secure state? I mean, I do not think it would help with
>> this:
>>
>> "In general, security mechanisms should be designed so that a failure
>> will follow the same execution path as disallowing the operation. For
>> example, application security methods, such as isAuthorized(),
>> isAuthenticated(), and validate(), should all return false if there is
>> an exception during processing. If security controls can throw
>> exceptions, they must be very clear about exactly what that condition
>> means. "
>>
>
> You are correct, that isn't the pg_xlog but yes, PostgreSQL will throw an
> exception in those types of cases.
>
> Sincerely,
>
> JD
>
>
> --
> Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Announcing "I'm offended" is basically telling the world you can't
> control your own emotions, so everyone else should do it for you.
>

Re: [GENERAL] Failing to known state

[oleg yusim]

Hi Adrian,

I meant a scenario, when user is trying to connect to database (doesn't
matter what interface) and database fails at this moment. If all
authentication/authorization/validation functions are written to return
false in case of abnormal termination, we are fine. If not, we can
potentially encounter the situation when database fails into state where
user is given greater privileges than he/she should or even authenticated,
when he/she shouldn't.

Thanks,

Oleg

On Tue, Jan 5, 2016 at 5:34 PM, Adrian Klaver 
wrote:

> On 01/05/2016 03:21 PM, oleg yusim wrote:
>
>> Thanks JD.
>>
>>  From what I read about WAL (you have been referring to this:
>> http://www.postgresql.org/docs/current/static/wal-internals.html
>> pg_xlog, right?) it allows us to know what happened, but does it
>> warranty known secure state? I mean, I do not think it would help with
>> this:
>>
>> "In general, security mechanisms should be designed so that a failure
>> will follow the same execution path as disallowing the operation. For
>> example, application security methods, such as isAuthorized(),
>> isAuthenticated(), and validate(), should all return false if there is
>> an exception during processing. If security controls can throw
>> exceptions, they must be very clear about exactly what that condition
>> means. "
>>
>
> Not sure what you are talking about above. the application as in the
> client application connecting to the database or the database application
> itself?
>
>
>> Right?
>>
>> Thanks,
>>
>> Oleg
>>
>>
>> On Tue, Jan 5, 2016 at 5:14 PM, Joshua D. Drake > > wrote:
>>
>> On 01/05/2016 03:09 PM, oleg yusim wrote:
>>
>>
>>
>> The question here, what is PostreSQL 9.4.5 (hosted on Linux box)
>> behavior? Does it fail to known/secure state in these 3 cases? I
>> tried
>> to find the description of the way PostgreSQL fails in this
>> regard, but
>> didn't find much.
>>
>>
>> Based on what you pasted, PostgreSQL does fail to a known state.
>> That is the whole point of the xlog.
>>
>> Sincerely,
>>
>> JD
>>
>>
>> Thanks,
>>
>> Oleg
>>
>>
>>
>> --
>> Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
>> 
>> PostgreSQL Centered full stack support, consulting and development.
>> Announcing "I'm offended" is basically telling the world you can't
>> control your own emotions, so everyone else should do it for you.
>>
>>
>>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>

Re: [GENERAL] Failing to known state

[John R Pierce]

On 1/5/2016 4:12 PM, oleg yusim wrote:
I meant a scenario, when user is trying to connect to database 
(doesn't matter what interface) and database fails at this moment. If 
all authentication/authorization/validation functions are written to 
return false in case of abnormal termination, we are fine. If not, we 
can potentially encounter the situation when database fails into state 
where user is given greater privileges than he/she should or even 
authenticated, when he/she shouldn't.





if the postgres server processes terminate for any reason, there's 
nothing to connect to.  the client application will get a error like 
'connection refused' back from the connection attempt, or if it was 
already connected and the server aborts, the next query will return an 
error like CONNECTION_BAD.  there's no possible privilege elevation.






--
john r pierce, recycling bits in santa cruz

Re: [GENERAL] Failing to known state

[Joe Conway]

On 01/05/2016 04:32 PM, John R Pierce wrote:
> On 1/5/2016 4:12 PM, oleg yusim wrote:
>> I meant a scenario, when user is trying to connect to database
>> (doesn't matter what interface) and database fails at this moment. If
>> all authentication/authorization/validation functions are written to
>> return false in case of abnormal termination, we are fine. If not, we
>> can potentially encounter the situation when database fails into state
>> where user is given greater privileges than he/she should or even
>> authenticated, when he/she shouldn't.
> 
> if the postgres server processes terminate for any reason, there's
> nothing to connect to.  the client application will get a error like
> 'connection refused' back from the connection attempt, or if it was
> already connected and the server aborts, the next query will return an
> error like CONNECTION_BAD.  there's no possible privilege elevation.

+1

I think you can call this one "Applicable -- Inherently Meets"

Joe

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



signature.asc
Description: OpenPGP digital signature

[GENERAL] Failing to known state

[oleg yusim]

Greetings,

One more security requirement I'm battling with:



The DBMS must fail to a secure state if system initialization fails,
shutdown fails, or aborts fail.

Failure to a known state can address safety or security in accordance with
the mission/business needs of the organization.

Failure to a known secure state helps prevent a loss of confidentiality,
integrity, or availability in the event of a failure of the information
system or a component of the system.

Failure to a known safe state helps prevent systems from failing to a state
that may cause loss of data or unauthorized access to system resources.
Systems that fail suddenly and with no incorporated failure state planning
may leave the hosting system available but with a reduced security
protection capability. Preserving information system state data also
facilitates system restart and return to the operational mode of the
organization with less disruption of mission/business processes.

Databases must fail to a known consistent state. Transactions must be
successfully completed or rolled back.

In general, security mechanisms should be designed so that a failure will
follow the same execution path as disallowing the operation. For example,
application security methods, such as isAuthorized(), isAuthenticated(),
and validate(), should all return false if there is an exception during
processing. If security controls can throw exceptions, they must be very
clear about exactly what that condition means.

Abort refers to stopping a program or function before it has finished
naturally. The term abort refers to both requested and unexpected
terminations.



The question here, what is PostreSQL 9.4.5 (hosted on Linux box) behavior?
Does it fail to known/secure state in these 3 cases? I tried to find the
description of the way PostgreSQL fails in this regard, but didn't find
much.

Thanks,

Oleg

Re: [GENERAL] Failing to known state

[oleg yusim]

Thanks JD.

>From what I read about WAL (you have been referring to this:
http://www.postgresql.org/docs/current/static/wal-internals.html pg_xlog,
right?) it allows us to know what happened, but does it warranty known
secure state? I mean, I do not think it would help with this:

"In general, security mechanisms should be designed so that a failure will
follow the same execution path as disallowing the operation. For example,
application security methods, such as isAuthorized(), isAuthenticated(),
and validate(), should all return false if there is an exception during
processing. If security controls can throw exceptions, they must be very
clear about exactly what that condition means. "

Right?

Thanks,

Oleg



On Tue, Jan 5, 2016 at 5:14 PM, Joshua D. Drake 
wrote:

> On 01/05/2016 03:09 PM, oleg yusim wrote:
>
>
>>
>> The question here, what is PostreSQL 9.4.5 (hosted on Linux box)
>> behavior? Does it fail to known/secure state in these 3 cases? I tried
>> to find the description of the way PostgreSQL fails in this regard, but
>> didn't find much.
>>
>>
> Based on what you pasted, PostgreSQL does fail to a known state. That is
> the whole point of the xlog.
>
> Sincerely,
>
> JD
>
>
> Thanks,
>>
>> Oleg
>>
>
>
> --
> Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
> PostgreSQL Centered full stack support, consulting and development.
> Announcing "I'm offended" is basically telling the world you can't
> control your own emotions, so everyone else should do it for you.
>

Re: [GENERAL] Failing to known state

[Joshua D. Drake]

On 01/05/2016 03:21 PM, oleg yusim wrote:

Thanks JD.

 From what I read about WAL (you have been referring to this:
http://www.postgresql.org/docs/current/static/wal-internals.html
pg_xlog, right?) it allows us to know what happened, but does it
warranty known secure state? I mean, I do not think it would help with this:

"In general, security mechanisms should be designed so that a failure
will follow the same execution path as disallowing the operation. For
example, application security methods, such as isAuthorized(),
isAuthenticated(), and validate(), should all return false if there is
an exception during processing. If security controls can throw
exceptions, they must be very clear about exactly what that condition
means. "


You are correct, that isn't the pg_xlog but yes, PostgreSQL will throw 
an exception in those types of cases.


Sincerely,

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


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

Re: [GENERAL] Failing to known state

[Joshua D. Drake]

On 01/05/2016 03:09 PM, oleg yusim wrote:




The question here, what is PostreSQL 9.4.5 (hosted on Linux box)
behavior? Does it fail to known/secure state in these 3 cases? I tried
to find the description of the way PostgreSQL fails in this regard, but
didn't find much.



Based on what you pasted, PostgreSQL does fail to a known state. That is 
the whole point of the xlog.


Sincerely,

JD



Thanks,

Oleg



--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.


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

Re: [GENERAL] Failing to known state

[Adrian Klaver]

On 01/05/2016 03:21 PM, oleg yusim wrote:

Thanks JD.

 From what I read about WAL (you have been referring to this:
http://www.postgresql.org/docs/current/static/wal-internals.html
pg_xlog, right?) it allows us to know what happened, but does it
warranty known secure state? I mean, I do not think it would help with this:

"In general, security mechanisms should be designed so that a failure
will follow the same execution path as disallowing the operation. For
example, application security methods, such as isAuthorized(),
isAuthenticated(), and validate(), should all return false if there is
an exception during processing. If security controls can throw
exceptions, they must be very clear about exactly what that condition
means. "


Not sure what you are talking about above. the application as in the 
client application connecting to the database or the database 
application itself?




Right?

Thanks,

Oleg


On Tue, Jan 5, 2016 at 5:14 PM, Joshua D. Drake > wrote:

On 01/05/2016 03:09 PM, oleg yusim wrote:



The question here, what is PostreSQL 9.4.5 (hosted on Linux box)
behavior? Does it fail to known/secure state in these 3 cases? I
tried
to find the description of the way PostgreSQL fails in this
regard, but
didn't find much.


Based on what you pasted, PostgreSQL does fail to a known state.
That is the whole point of the xlog.

Sincerely,

JD


Thanks,

Oleg



--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564

PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.





--
Adrian Klaver
adrian.kla...@aklaver.com


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