Skip to content

Security and User Privacy

Jump to bottom Edit New page
Seamus Tuohy edited this page Apr 23, 2014 · 3 revisions

Loading Settings

We are in the vetting state for this work. Currently we are planning to write up a mini-architecture for the following process. Once it is complete we are going to get this architecture vetted as widelyy as possible before implementation.

  • Upon start_up the commotion client will be in anonymous mode.
    • This mode will save no extension settings and will use temporary files to store and configs that are generated for connecting to, or creating, Commotion networks.
  • Upon logging in the following will happen.
    • The user settings manager will identify an encrypted settings file based upon the user-name entered. It will then use the password given to ask the [GnuPG Interface](gnupg integration) to decrypt that settings file.
    • If it fails to decrypt the settings file then the password was incorrect. In this way we push out log-in security on to GnuPG and only have to ensure that we are following best practices for working with GnuPG>
    • If it succeeds then the settings file is decrypted to a temporary files that will be read from, and written to.
  • Periodically throughout use, and upon logging out or exiting the application the settings file will be encrypted again and saved.

Providing settings access to Extensions

The settings manager will have a limited set of saving and loading functions provided to extensions to allow them to use the secure user-settings files. This will have a great degree of data sanatization and isolation from the actual user settings file. Instead of providing access to the user-settings file it will simply provide a few functions for having the settings manager write or read from an isolated group within the settings file.

The model we are following is a settings 'chroot' with heavy sanatization of the objects that can be written to it.

GnuPG integration

We will be using the python-gnupg library for GnuPG integration. (python-gnupg docs).

Privilege Separation

The commotion client will need superuser permissions for some of the networking configuration it must do. As such, we will employ privilege separation in the application to isolate the code that actually runs as "root" to as few lines as possible. When the Commotion client is run it will fork out the privileged code and then drop privileges everywhere else. We will be using Moxie Marlinspikes privlage seperation in KnockKnock as a guide for implementing this feature.

Windows will require that we have fall-backs for the use of the os.getuid function. An example take from stackoverflow that will check for admin is shown below as an example.

import ctypes, os
try:
 is_admin = os.getuid() == 0
except AttributeError:
 is_admin = ctypes.windll.shell32.IsUserAnAdmin() != 0

print is_admin

A narrative description of the standard step by step process in unix is in the python-lust readme. The code for this can be found here.

Resources

CODE EXAMPLES FOR SETTINGS ABSTRACTION

Add a custom footer
Add a custom sidebar
Clone this wiki locally