Mirrors
/
gparted
mirror of https://gitlab.gnome.org/GNOME/gparted.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gparted/tests/test_PasswordRAMStore.cc

296 lines
9.1 KiB
C++
Raw Normal View History

Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
/* Copyright (C) 2017 Mike Fleetwood
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, see <http://www.gnu.org/licenses/>.
*/
/* Test PasswordRAMStore
*
Simplify obtaining address of password memory for unit tests (#795617) Use private access into the PasswordRAMStore class to directly obtain the address of the locked memory, rather than inferring it from the address of the first stored password. This simplifies PasswordRAMStoreTest::SetUpTestCase() and avoids encoding most of the implementation knowledge that the first password will be stored at the start of the protected memory. Bug 795617 - Implement opening and closing of LUKS mappings
2017-11-10 00:57:06 -07:00
* NOTE:
* As well as calling the public API of PasswordRAMStore this unit testing also accesses
* the private members of PasswordRAMStore and uses knowledge of the implementation,
Add unit testing of erasing all passwords (#795617) Test that all passwords are zeroed by PasswordRAMStore::erase_all(), the same method as used in the PasswordRAMStore destructor. Bug 795617 - Implement opening and closing of LUKS mappings
2017-11-10 00:39:04 -07:00
* making this white box testing. This is so that the hidden behaviour of zeroing
* password storing memory before and after use can be tested.
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
*
* WARNING:
* Each test fixture would normally initialise separate resources to make the tests
* independent of each other. However the password store is a single long lived shared
* resource. Therefore, so that each test fixture is independent of all the others, the
* password store must be returned to it's original state of being empty before each
* fixture completes.
*
* Reference:
* Google Test, Advanced Guide, Sharing Resources Between Tests in the Same Test Case
* https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#sharing-resources-between-tests-in-the-same-test-case
*/
#include "PasswordRAMStore.h"
#include "gtest/gtest.h"
#include <stdio.h>
#include <stddef.h>
#include <string.h>
#include <string>
#include <glibmm/ustring.h>
namespace GParted
{
// Generate repeatable unique keys
static const char * gen_key( unsigned int i )
{
static char buf[14];
snprintf( buf, sizeof( buf ), "key%u", i );
return buf;
}
// Generate repeatable "passwords" exactly 20 characters long
static const char * gen_passwd( unsigned int i )
{
static char buf[21];
Resolve compiler warning from gen_password() More recent g++ versions produce these warnings: test_PasswordRAMStore.cc: In member function ‘virtual void GParted::PasswordRAMStoreTest_TotalErasure_Test::TestBody()’: test_PasswordRAMStore.cc:61:32: warning: ‘ ’ directive output truncated writing 20 bytes into a region of size 10 [-Wformat-truncation=] snprintf( buf, sizeof( buf ), "password%03u ", i ); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ test_PasswordRAMStore.cc:61:10: note: ‘snprintf’ output 32 bytes into a destination of size 21 snprintf( buf, sizeof( buf ), "password%03u ", i ); ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ snprintf() [1] truncates the printed string to the specified size so didn't overflow the buffer. However clear the warning by making the formatted string always exactly 20 characters long, followed by the terminating NUL character to exactly fill the buffer. [1] print3(f) - Linux manual page https://man7.org/linux/man-pages/man3/snprintf.3.html "The functions snprintf() and vsnprintf() write at most size bytes (including the terminating null byte ('\0')) to str. "
2023-02-08 14:04:08 -07:00
snprintf(buf, sizeof(buf), "password%03u ", i%1000);
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
return buf;
}
static bool mem_is_zero( const char * mem, size_t len )
{
while ( len-- > 0 )
{
if ( *mem++ != '\0' )
{
return false;
}
}
return true;
}
// Explicit test fixture class for common setup and sharing of the underlying password
// store address.
class PasswordRAMStoreTest : public ::testing::Test
{
protected:
PasswordRAMStoreTest() : looked_up_pw( NULL ) {};
static void SetUpTestCase();
Add unit testing of erasing all passwords (#795617) Test that all passwords are zeroed by PasswordRAMStore::erase_all(), the same method as used in the PasswordRAMStore destructor. Bug 795617 - Implement opening and closing of LUKS mappings
2017-11-10 00:39:04 -07:00
static void erase_all() { PasswordRAMStore::erase_all(); };
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
static const char * protected_mem;
std::string pw;
const char * looked_up_pw;
size_t looked_up_len;
};
// Initialise test case class static member.
const char * PasswordRAMStoreTest::protected_mem = NULL;
const size_t ProtectedMemSize = 4096; // [Implementation knowledge: size]
Simplify obtaining address of password memory for unit tests (#795617) Use private access into the PasswordRAMStore class to directly obtain the address of the locked memory, rather than inferring it from the address of the first stored password. This simplifies PasswordRAMStoreTest::SetUpTestCase() and avoids encoding most of the implementation knowledge that the first password will be stored at the start of the protected memory. Bug 795617 - Implement opening and closing of LUKS mappings
2017-11-10 00:57:06 -07:00
// Common test case initialisation recording the underlying password store address.
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
void PasswordRAMStoreTest::SetUpTestCase()
{
Simplify obtaining address of password memory for unit tests (#795617) Use private access into the PasswordRAMStore class to directly obtain the address of the locked memory, rather than inferring it from the address of the first stored password. This simplifies PasswordRAMStoreTest::SetUpTestCase() and avoids encoding most of the implementation knowledge that the first password will be stored at the start of the protected memory. Bug 795617 - Implement opening and closing of LUKS mappings
2017-11-10 00:57:06 -07:00
protected_mem = PasswordRAMStore::get_protected_mem();
ASSERT_TRUE( protected_mem != NULL ) << __func__ << "(): No locked virtual memory for password RAM store";
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
}
TEST_F( PasswordRAMStoreTest, Initialisation )
{
// Test locked memory is initialised with all zeros.
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
}
TEST_F( PasswordRAMStoreTest, UnknownPasswordLookup )
{
// Test lookup of non-existent password fails.
looked_up_pw = PasswordRAMStore::lookup( "key-unknown" );
EXPECT_TRUE( looked_up_pw == NULL );
}
TEST_F( PasswordRAMStoreTest, UnknownPasswordErasure )
{
// Test erase non-existent password fails.
EXPECT_FALSE( PasswordRAMStore::erase( "key-unknown" ) );
}
TEST_F( PasswordRAMStoreTest, SinglePassword )
{
// Test a single password can be stored, looked up and erased (and zeroed).
pw = "password";
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
EXPECT_TRUE( PasswordRAMStore::store( "key-single", pw.c_str() ) );
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
looked_up_pw = PasswordRAMStore::lookup( "key-single" );
EXPECT_STREQ( pw.c_str(), looked_up_pw );
looked_up_len = strlen( looked_up_pw );
EXPECT_TRUE( PasswordRAMStore::erase( "key-single" ) );
EXPECT_TRUE( mem_is_zero( looked_up_pw, looked_up_len ) );
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
}
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
TEST_F( PasswordRAMStoreTest, IdenticalPassword )
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
{
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
// Test a password can be saved twice with the same key and looked up (and the
// single password can be erased and zeroed).
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
pw = "password";
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
EXPECT_TRUE( PasswordRAMStore::store( "key-single", pw.c_str() ) );
EXPECT_TRUE( PasswordRAMStore::store( "key-single", pw.c_str() ) );
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
looked_up_pw = PasswordRAMStore::lookup( "key-single" );
EXPECT_STREQ( pw.c_str(), looked_up_pw );
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
looked_up_len = strlen( looked_up_pw );
EXPECT_TRUE( PasswordRAMStore::erase( "key-single" ) );
EXPECT_TRUE( mem_is_zero( looked_up_pw, looked_up_len ) );
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
}
TEST_F( PasswordRAMStoreTest, ReplacePassword )
{
// Test a password can be saved and looked up, then saved again with a different
// password using the same key and looked up (and the single replaced password
// is erased and zeroed).
pw = "password";
EXPECT_TRUE( PasswordRAMStore::store( "key-single", pw.c_str() ) );
looked_up_pw = PasswordRAMStore::lookup( "key-single" );
EXPECT_STREQ( pw.c_str(), looked_up_pw );
pw = "password2";
EXPECT_TRUE( PasswordRAMStore::store( "key-single", pw.c_str() ) );
looked_up_pw = PasswordRAMStore::lookup( "key-single" );
EXPECT_STREQ( pw.c_str(), looked_up_pw );
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
looked_up_len = strlen( looked_up_pw );
EXPECT_TRUE( PasswordRAMStore::erase( "key-single" ) );
EXPECT_TRUE( mem_is_zero( looked_up_pw, looked_up_len ) );
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
}
TEST_F( PasswordRAMStoreTest, OneHundredPasswordsForwards )
{
// Test 100, 20 character passwords can be stored, looked up and erased (and
// zeroed). Passwords are erased forwards (first stored to last stored).
unsigned int i;
for ( i = 0 ; i < 100 ; i ++ )
{
pw = gen_passwd( i );
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
EXPECT_TRUE( PasswordRAMStore::store( gen_key(i), pw.c_str() ) );
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
}
for ( i = 0 ; i < 100 ; i ++ )
{
pw = gen_passwd( i );
looked_up_pw = PasswordRAMStore::lookup( gen_key(i) );
EXPECT_STREQ( pw.c_str(), looked_up_pw );
}
for ( i = 0 ; i < 100 ; i ++ )
{
pw = gen_passwd( i );
looked_up_pw = PasswordRAMStore::lookup( gen_key(i) );
looked_up_len = strlen( looked_up_pw );
EXPECT_TRUE( PasswordRAMStore::erase( gen_key(i) ) );
EXPECT_TRUE( mem_is_zero( looked_up_pw, looked_up_len ) );
}
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
}
TEST_F( PasswordRAMStoreTest, OneHundredPasswordsBackwards )
{
// Test 100, 20 character passwords can be stored, looked up and erased (and
// zeroed). Passwords are erased backwards (last stored to first stored).
unsigned int i;
for ( i = 0 ; i < 100 ; i ++ )
{
pw = gen_passwd( i );
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
EXPECT_TRUE( PasswordRAMStore::store( gen_key(i), pw.c_str() ) );
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
}
for ( i = 0 ; i < 100 ; i ++ )
{
pw = gen_passwd( i );
looked_up_pw = PasswordRAMStore::lookup( gen_key(i) );
EXPECT_STREQ( pw.c_str(), looked_up_pw );
}
for ( i = 100; i-- > 0 ; )
{
pw = gen_passwd( i );
looked_up_pw = PasswordRAMStore::lookup( gen_key(i) );
looked_up_len = strlen( looked_up_pw );
EXPECT_TRUE( PasswordRAMStore::erase( gen_key(i) ) );
EXPECT_TRUE( mem_is_zero( looked_up_pw, looked_up_len ) );
}
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
}
TEST_F( PasswordRAMStoreTest, LongPassword )
{
// Test a 4095 byte password can be stored and looked up (and erased and zeroed).
// [Implementation knowledge: size]
pw = std::string( ProtectedMemSize-1, 'X' );
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
EXPECT_TRUE( PasswordRAMStore::store( "key-long", pw.c_str() ) );
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
looked_up_pw = PasswordRAMStore::lookup( "key-long" );
EXPECT_STREQ( pw.c_str(), looked_up_pw );
looked_up_len = strlen( looked_up_pw );
EXPECT_TRUE( PasswordRAMStore::erase( "key-long" ) );
EXPECT_TRUE( mem_is_zero( looked_up_pw, looked_up_len ) );
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
}
TEST_F( PasswordRAMStoreTest, TooLongPassword )
{
// Test a 4096 byte password can't be stored nor looked up or erased.
// [Implementation knowledge: size]
std::string pw = std::string( ProtectedMemSize, 'X' );
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
EXPECT_FALSE( PasswordRAMStore::store( "key-too-long", pw.c_str() ) );
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
looked_up_pw = PasswordRAMStore::lookup( "key-too-long" );
EXPECT_TRUE( looked_up_pw == NULL );
Erase correct key in unit test PasswordRAMStoreTest.TooLongPassword Was attempting to erase the wrong key "key-long" for the test. It should be erasing "key-too-long". Fix this. Given that that line in the test was to erase a non-existent key and confirm failure; the test passed before with the wrong non-existent key, and still passes with the right non-existent key. Clearly a cut and paste error as a result of copying the previous LongPassword test when initially added in: c6657aab9efe8cefece2017bee4bef9ece607e73 Add unit tests for PasswordRAMStore module (#795617)
2019-06-29 02:46:43 -06:00
EXPECT_FALSE(PasswordRAMStore::erase("key-too-long"));
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
}
Add unit testing of erasing all passwords (#795617) Test that all passwords are zeroed by PasswordRAMStore::erase_all(), the same method as used in the PasswordRAMStore destructor. Bug 795617 - Implement opening and closing of LUKS mappings
2017-11-10 00:39:04 -07:00
TEST_F( PasswordRAMStoreTest, TotalErasure )
{
// Test all passwords are erased (and zeroed using the same code called during
// password cache destruction).
unsigned int i;
for ( i = 0 ; i < 100 ; i ++ )
{
pw = gen_passwd( i );
Change to insert or replace PasswordRAMStore::store() interface (#795617) Replace the insert() method (which reports an error when inserting a password with a key which already exists) with the store() method which replaces or inserts the password depending on whether the key already exists or not respectively. There is also an optimisation that nothing is changed if the password to be replaced is the same as the one already stored. The code in Win_GParted::open_encrypted_partition() is simplified now it doesn't have to implement this pattern of behaviour itself. Bug 795617 - Implement opening and closing of LUKS mappings
2018-04-23 10:15:23 -06:00
EXPECT_TRUE( PasswordRAMStore::store( gen_key(i), pw.c_str() ) );
Add unit testing of erasing all passwords (#795617) Test that all passwords are zeroed by PasswordRAMStore::erase_all(), the same method as used in the PasswordRAMStore destructor. Bug 795617 - Implement opening and closing of LUKS mappings
2017-11-10 00:39:04 -07:00
}
EXPECT_FALSE( mem_is_zero( protected_mem, ProtectedMemSize ) );
PasswordRAMStoreTest::erase_all();
EXPECT_TRUE( mem_is_zero( protected_mem, ProtectedMemSize ) );
}
Add unit tests for PasswordRAMStore module (#795617) As noted in comments: 1) This is white box testing because it uses implementation knowledge to look through the API to the internals of the password store. 2) It is not currently possible to test that the passwords are zeroed when the store is destroyed. However zeroing of memory is being tested when individual passwords are erased. Bug 795617 - Implement opening and closing of LUKS mappings
2017-10-09 04:51:07 -06:00
} // namespace GParted