Обсуждение: Failing to known state
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
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.
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 <jd@commandprompt.com> 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,
JDThanks,
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.
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.
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 <jd@commandprompt.com > <mailto:jd@commandprompt.com>> 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 > <tel: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.klaver@aklaver.com
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 <jd@commandprompt.com> 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.
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 <adrian.klaver@aklaver.com> 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 <jd@commandprompt.com
<mailto:jd@commandprompt.com>> 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
<tel: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.klaver@aklaver.com
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
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
Вложения
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.klaver@aklaver.com
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 <pierce@hogranch.com> 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
Hi Joe,
Exactly how I marked it :)
Thanks,
Oleg
On Tue, Jan 5, 2016 at 6:50 PM, Joe Conway <mail@joeconway.com> 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
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 <adrian.klaver@aklaver.com> 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.klaver@aklaver.com