Writing secure code

Collaboration diagram for 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

template<typename T>
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().

template<typename T>
T* FX::Secure::calloc ( size_t  no,
size_t  size 
) throw () [inline]

Allocates memory in the secure heap

Referenced by FX::calloc().

template<typename T>
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[]().


(C) 2002-2008 Niall Douglas. Some parts (C) to assorted authors.
Generated on Fri Jun 13 21:55:19 2008 for TnFOX by doxygen v1.5.6