Writing secure code
|
Detailed Description
TnFOX goes considerably further than any other GUI toolkit library that I know of in allowing you to write secure code. There are four fundamental requirements for secure code: robustness, access control, encryption and containing sensitive data.TnFOX's extensive error handling facilities are second-to-none and allow extremely robust code to be easily written - perhaps even better than any other portable library for mainstream systems available. See the section Transaction Rollbacks as well as the documentation for FX::FXException.
Managing access control is tough to do across systems portably as they vary so much. Yet TnFOX's FX::FXACL and FX::FXACLEntity enable most of the native access control security features available on both Windows NT and POSIX Unix for files (FX::QFile), directories, named pipes (FX::QPipe) and memory mapped sections (FX::QMemMap).
Via the OpenSSL library, TnFOX also provides a range of strong encryption facilities (FX::QSSLDevice), strong public and private key manipulation (FX::FXSSLPKey, FX::FXSSLKey) as well as a portable high-quality entropy gatherer (FX::Secure::Randomness) and fast cryptographically secure hashing facilities (FX::Secure::TigerHash).
Sensitive data when on disc should be accessed via i/o devices with the IO_ShredTruncate flag set as the open mode - this shreds any data truncated off the file, thus ensuring data does not leak into the disc drive's free space. Similarly if deleting a sensitive data file you should open it, truncate(0) it, and close before deletion. You can manually shred data using FX::QIODevice::shredData().
Sensitive data when in memory should be allocated from the FX::Secure namespace which provides its own new, delete, malloc() and free() implementations which use a custom heap kept separately from the normal free store. This heap is permanently locked into memory to prevent paging to virtual memory swap files and is zeroed on process exit, no matter how that exit occurs (eg; a segmentation fault). This is to make it harder for secure data to be retrieved by a number of process-intrusion methods.
Needless to say, calls to these operators must be matched ie; you cannot mix and match memory allocated within FX::Secure with calls made outside. This unfortunately causes many compilers not entirely namespace conformant to generate bad code.
Lastly, an often overlooked issue is securely containing passwords entered by the user. FX::FXTextField with TEXTFIELD_PASSWD is insecure as it uses an FX::FXString to hold the password - however, it is extremely unlikely the same user entering a password will want to retrieve it via malicious means (unless they forget it :) ). Far more likely is that a password entered by a privileged user earlier in the session may be retrieved maliciously later on - to avoid this, I have patched FXTextField to zero its contents on destruction when TEXTFIELD_PASSWD is set. This implies that if you have any dialogs taking passwords as input, you should always destroy them when done - don't leave the dialog hanging around in memory.
Namespaces | |
| namespace | Secure |
Classes | |
| class | FX::FXACLEntity |
| Something which can be permitted or denied to do something within this operating system. More... | |
| class | FX::FXACL |
| Provides a portable Access Control List. More... | |
| class | FX::FXACLIterator |
| Allows indexing of an ACL. More... | |
| struct | FX::Secure::TigerHashValue |
| Represents a 192 bit Tiger hash value. More... | |
| class | FX::Secure::Randomness |
| A source of true entropy. More... | |
| class | FX::Secure::PRandomness |
| A cryptographically secure source of pseudo entropy. More... | |
| class | FX::Secure::TigerHash |
| An implementation of the Tiger fast hashing algorithm. More... | |
| class | FX::QIODevice |
| The abstract base class for all i/o classes in TnFOX (Qt compatible). More... | |
| class | FX::FXSSLPKey |
| A container holding a variable length asymmetric encryption key. More... | |
| class | FX::QSSLDevice |
| An i/o device encrypting what goes through it. More... | |
Functions | |
| FXAPI void * | operator new (size_t size, const FX::Secure::heap &) throw (std::bad_alloc) |
| FXAPI void * | operator new[] (size_t size, const FX::Secure::heap &) throw (std::bad_alloc) |
| FXAPI void | operator delete (void *p, const FX::Secure::heap &) throw () |
| FXAPI void | operator delete[] (void *p, const FX::Secure::heap &) throw () |
| template<typename T> | |
| T * | FX::Secure::malloc (size_t size) throw () |
| template<typename T> | |
| T * | FX::Secure::calloc (size_t no, size_t size) throw () |
| template<typename T> | |
| void | FX::Secure::free (T *p) throw () |
Function Documentation
| FXAPI void* operator new | ( | size_t | size, | |
| const FX::Secure::heap & | ||||
| ) | throw (std::bad_alloc) |
operator new allocating in the secure heap
| FXAPI void* operator new[] | ( | size_t | size, | |
| const FX::Secure::heap & | ||||
| ) | throw (std::bad_alloc) |
operator new[] allocating in the secure heap
| FXAPI void operator delete | ( | void * | p, | |
| const FX::Secure::heap & | ||||
| ) | throw () |
operator delete freeing in the secure heap
| FXAPI void operator delete[] | ( | void * | p, | |
| const FX::Secure::heap & | ||||
| ) | throw () |
operator delete[] freeing in the secure heap
| T* FX::Secure::malloc | ( | size_t | size | ) | throw () [inline] |
Allocates memory in the secure heap
Referenced by FX::malloc(), operator new(), operator new[](), and FX::strdup().
| T* FX::Secure::calloc | ( | size_t | no, | |
| size_t | size | |||
| ) | throw () [inline] |
Allocates memory in the secure heap
Referenced by FX::calloc().
| void FX::Secure::free | ( | T * | p | ) | throw () [inline] |
Frees memory previously allocated in the secure heap
Referenced by FX::free(), operator delete(), and operator delete[]().
