Kushal Das4

FOSS and life. Kushal Das talks here.

kushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion

Using Ansible to maintain your Qubes system

From the time I have started using Qubes OS, How to create and setup new AppVMs in an efficient way? remained an open question for me. I was mostly using the command line tool to create any new AppVMs and then manually setting all the properties after creation. I also did the package installations and other setup inside of the VMs manually.

If you never heard of Qubes before, you should check it out. Qubes takes a different approach to security, security by compartmentalization, different applications are separated by Qubes (VMs) . The base is running Fedora and then all other VMs are on top of Xen. It also provides a very tight integration of the tools to give a pleasant experience.

When I asked about how people maintain different VMs or templateVMs (from which the normal VMs spawn off), the answer was mostly bash scripts. The tools provided by the Qubes team are friendly to scripting. Though the official way to managing VMs is done by Salt project.

As we (at Freedom of the Press Founation) are working towards a Qubes based desktop client for SecureDrop, we also started using Salt to maintain the states of the VMs. I personally found Salt to be very confusing and a bit difficult to learn.

From the mailing list I also found out about https://github.com/Rudd-O/ansible-qubes, but, as I started reading the README, I figured that Salt is being used here too in the background. That made me rethink about the Ansible as a choice to maintain my Qubes.

Last weekend I pinged Trishna for some pointers on writing new plugins for Ansible, and later at night I also talked with Toshio about the Ansible plugins + modules.

Introducing Qubes Ansible

The result of those chats is Qubes Ansible. It has a qubesos module and a qubes connection plugin for Ansible.

I already have a PR opened to add the connection plugin into Ansible.

The actual module will still require a lot of work to become feature complete with the existing command line tools and also with the Salt. This project is under active development.

Good thing is that I am getting feedback+patches from the #qubes IRC channel (on Freenode). From the Qubes development team, marmarek provided some real valuable input to make the plugin easier to use.

Example playbook

---
- hosts: localhost
  connection: local

  tasks:
    - name: Make sure the development VM is present
      qubesos:
        guest: development2
        state: present
        properties:
          memory: 1200
          maxmem: 1400
          netvm: 'sys-firewall'
          template: 'debian-9'
          label: "blue"

    - name: Run the VM
      qubesos:
        guest: development2
        state: running

You can use the above playbook to create a development2 AppVM with the exact properties you want. The examples page has all the available options documented.

If you are using Qubes, please give it a try, and tell us how can we improve your experience of maintaining the system with Ansible. You can provide feedback in a Github issue or talk directly in the #qubes IRC channel.

SecureDrop development sprint in PyCon 2018

SecureDrop will take part in PyCon US development sprints (from 14th to 17th May). This will be first time for the SecureDrop project to present in the sprints.

If you never heard of the project before, SecureDrop is an open source whistleblower submission system that media organizations can install to securely accept documents from anonymous sources. Currently, dozens of news organizations including The Washington Post, The New York Times, The Associated Press, USA Today, and more, use SecureDrop to preserve the anonymous tipline in an era of mass surveillance. SecureDrop is installed on-premises in the news organizations, and journalists and source both use a web application to interact with the system. It was originally coded by the late Aaron Swartz and is now managed by Freedom of the Press Foundation.

How to prepare for the sprints

The source code of the project is hosted on Github.

The web applications, administration CLI tool, and a small Qt-based GUI are all written in Python. We use Ansible heavily for the orchestration. You can setup the development environment using Docker. This section of the documentation is a good place to start.

A good idea would be to create the initial Docker images for the development before the sprints. We have marked many issues for PyCon Sprints and also there are many documentation issues.

Another good place to look is the tests directorty. We use pytest for most of our test cases. We also have Selenium based functional tests.

Where to find the team?

Gitter is our primary communication platform. During the sprint days, we will in the same room of the CPython development (as I will be working on both).

So, if you are in PyCon sprints, please visit us to know more and maybe, start contributing to the project while in sprints.

How to leak information securely?

There are times when one may have access to the information which can be very important for the world to know. But, sharing any such information safely to journalists is always a risky task. In the modern era of Internet communications, it is, on one hand, very easy to share documents over Internet, and on the other hand, easy for the government/private organizations to track the source using just the metadata. For example, we know that GPG can encrypt our emails properly and no one can read the content, but one can easily figure out when someone mailed a journalist or vice-versa. Often, that information is enough to deanonymize a source.

SecureDrop is a free software project from Freedom of the Press Foundation which helps journalists and whistleblowers by providing an platform to share information anonymously. Read the end of the blog post to find out links to the different news organizations and SecureDrop. You may want to visit the URLs only using Tor browser (explained below). Even if you are just visiting the sites, your network admin can monitor which sites you are visiting, and the same goes for your home ISP (Internet Service Provider).

In this blog post I am going to talk about a few points to keep in mind while thinking/searching or actually leaking the information when using SecureDrop.

  • DO NOT SEARCH OR VIEW anything on your WORK NETWORK This is the most important point to start with. Make sure you are not researching or viewing any website which you want to contact in future while you are on your office network. This also means you are not supposed to use any of the office provided devices. Always use personal devices.

  • Make sure that the documents you want to share does not have anything which can identify you directly. For example if it has your employee code or any such unique number/name written on it.

  • Go to a public wifi place (for example, a coffee shop), and use that network. Once again, please do not use work or home network.

  • Use Tor Browser Download Tor Browser at your home computer and only use that to do any kind of research. Tor browser is a web browser pre-configured with Tor network so that it can make you anonymous. Tor Browser by default uses duckduckgo.com as the search engine. Duckduckgo do not keep track of what are you searching.

  • Download Tails OS, this can be installed on a USB drive. Remember that using Tails is harder than just using Tor browser in your daily computer. So, you will have to go through a few steps to install and use Tails. Tails uses the Tor network for all traffic by default. Use this on a personal laptop, and visit any public network space (for example coffee shop or shopping mall) and use their free wifi to upload the real documents. Now, we do maintain a directory listing of all the SecureDrop instances. Open this URL using Tor browser. The .onion addresses given in the site can only be opened using the Tor browser.

As I mentioned at the beginning of the post, SecureDrop is a free software which is developed by an active community, the source code is hosted at github. The primary application is written in Flask, and various other Python modules. Feel free to look at the issues, and contribute to the project as you wish.

Setting up SecureDrop 0.5rc2 in VMs for QA

Next week we have the 0.5 release of SecureDrop. SecureDrop is an open-source whistleblower submission system that media organizations can use to securely accept documents from and communicate with anonymous sources. It was originally created by the late Aaron Swartz and is currently managed by Freedom of the Press Foundation.

In this blog post I am going to tell you how can you set up a production instance of SecureDrop in VM(s) in your computer, and help us to test the system for the new release.

Required software

We provision our VM(s) using Vagrant. You will also need access to a GPG key (along with the private key) to test the whole workflow. The set up is done using Ansible playbooks.

Another important piece is a Tails VM for the administrator/journalist workstation. Download the latest (Tails 3.3) ISO from their website.

You will need at least 8GB RAM in your system so that you can have the 3 VM(s) required to test the full system.

Get the source code

For our test, we will first set up a SecureDrop 0.4.4 production system, and then we will update that to the 0.5rc release.

Clone the SecureDrop repository in a directory in your local computer. And then use the following commands to set up two VM(s). One of the VM is for the application server, and the other VM is the monitor server.

$ vagrant up /prod/ --no-provision

In case you don’t have the right image file for KVM, you can convert the Virtualbox image following this blog post.

Create a Tails VM

Follow this guide to create a virtualized Tails environment.

After the boot, remember to create a Persistence storage, and also setup a administrator password (you will have to provide the administrator password everytime you boot the Tails VM).

For KVM, remember to mark the drive as a removable USB storage and also mark it in the Booting Options section after the installation.

Then, you can mount the SecureDrop git repository inside the Tails VM, I used this guide for the same.

Also remember to change the Virtual Network Interface in the virt-manager to Virtual network ‘securedrop0’: NAT for the Tails VM.

Install SecureDrop 0.4.4 release in the production VM(s).

For the next part of the tutorial, I am assuming that the source code is at the ~/Persistent/securedrop directory.

Move to 0.4.4 tag

$ git checkout 0.4.4

We will also have remove a validation role from the 0.4.4 Ansible playbook, otherwise it will fail on a Tails 3.3 system.

diff --git a/install_files/ansible-base/securedrop-prod.yml b/install_files/ansible-base/securedrop-prod.yml
index 877782ff..37b27c14 100755
--- a/install_files/ansible-base/securedrop-prod.yml
+++ b/install_files/ansible-base/securedrop-prod.yml
@@ -11,8 +11,6 @@
# Don't clobber new vars file with old, just create it.
args:
creates: "{{ playbook_dir }}/group_vars/all/site-specific"
- roles:
- - { role: validate, tags: validate }
- name: Add FPF apt repository and install base packages.
hosts: securedrop

Create the configuration

In the host system make sure that you export your GPG public key to a file in the SecureDrop source directory, for my example I stored it in install_files/ansible-base/kushal.pub. I also have the exported insecure key from Vagrant. You can find that key at ~/.vagrant.d/insecure_private_key in your host system. Make sure to copy that file too in the SecureDrop source directory so that we can later access it from the Tails VM.

Inside of the Tails VM, give the following command to setup the dependencies.

$ ./securedrop-admin setup

Next, we will use the sdconfig command to create the configuration file.

$ ./securedrop-admin sdconfig

The above command will ask you many details, you can use the defaults in most cases. I am pasting my configuration file below, so that you can look at the example values I am using. The IP addresses are the default address for the production Vagrant VM(s). You should keep them the same as mine.

---
### Used by the common role ###
ssh_users: vagrant
dns_server: 8.8.8.8
daily_reboot_time: 4 # An integer between 0 and 23

# TODO Should use ansible to gather this info
monitor_ip: 10.0.1.5
monitor_hostname: mon
app_hostname: app
app_ip: 10.0.1.4

### Used by the app role ###
# The securedrop_header_image has to be in the install_files/ansible-base/ or
# the install_files/ansible-base/roles/app/files/ directory
# Leave set to empty to use the SecureDrop logo.
securedrop_header_image: ""
# The app GPG public key has to be in the install_files/ansible-base/ or
# install_files/ansible-base/roles/app/files/ directory
#
# The format of the app GPG public key can be binary or ASCII-armored,
# the extension also doesn't matter
#
# The format of the app gpg fingerprint needs to be all capital letters
# and zero spaces, e.g. "B89A29DB2128160B8E4B1B4CBADDE0C7FC9F6818"
securedrop_app_gpg_public_key: kushal.pub
securedrop_app_gpg_fingerprint: A85FF376759C994A8A1168D8D8219C8C43F6C5E1

### Used by the mon role ###
# The OSSEC alert GPG public key has to be in the install_files/ansible-base/ or
# install_files/ansible-base/roles/app/files/ directory
#
# The format of the OSSEC alert GPG public key can be binary or
# ASCII-armored, the extension also doesn't matter
#
# The format of the OSSEC alert GPG fingerprint needs to be all capital letters
# and zero spaces, e.g. "B89A29DB2128160B8E4B1B4CBADDE0C7FC9F6818"
ossec_alert_gpg_public_key: kushal.pub
ossec_gpg_fpr: A85FF376759C994A8A1168D8D8219C8C43F6C5E1
ossec_alert_email: kushaldas@gmail.com
smtp_relay: smtp.gmail.com
smtp_relay_port: 587
sasl_username: fakeuser
sasl_domain: gmail.com
sasl_password: fakepassword

### Use for backup restores ###
# If the `restore_file` variable is defined, Ansible will overwrite the state of
# the app server with the state from the restore file, which should have been
# created by a previous invocation of the "backup" role.
# To use uncomment the following line and enter the filename between the quotes.
# e.g. restore_file: "sd-backup-2015-01-15--21-03-32.tar.gz"
#restore_file: ""
securedrop_app_https_on_source_interface: False
securedrop_supported_locales: []

Starting the actual installation

Use the following two commands to start the installation.

$ ssh-add insecure_private_key
$ ./securedrop-admin install

Then wait for a while for the installation to finish.

Configure the Tails VM as a admin workstation

$ ./securedrop-admin tailsconfig

The above command expects that the previous installation step finished without any issue. The addresses for the source and journalist interfaces can be found in the install_files/ansible-base/*ths files at this moment.

After this command, you should see two desktop shortcuts on your Tails desktop, one pointing to the source interface, and one for journalist interface. Double click on the source interface and make sure that you can view the source interface and the SecureDrop version mentioned in the page is 0.4.4.

Now update the systems to the latest SecureDrop rc release

The following commands in the Tails VM will help you to update to the latest RC release.

$ source .venv/bin/activate
$ cd install_files/ansible-base
$ torify wget https://gist.githubusercontent.com/conorsch/e7556624df59b2a0f8b81f7c0c4f9b7d/raw/86535a6a254e4bd72022865612d753042711e260/securedrop-qa.yml`
$ ansible-playbook -vv --diff securedrop-qa.yml

Then we will SSH into both app and mon VM(s), and give the following the command to update to the latest RC.

$ sudo cron-apt -i -s

Note: You can use ssh app and ssh mon to connect to the systems. You can also checkout the release/0.5 branch and rerun the tailsconfig command. That will make sure the desktop shortcuts are trusted by default.

After you update both the systems, if you reopen the source interface in the Tails VM again, you should see version mentioned as a RC release.

Now, if you open up the source interface onion address in the Tor browser on your computer, you should be able to submit documents/messages.

SecureDrop hackathon at EFF office next week

On December 7th from 6PM we are having a SecureDrop hackathon at the EFF office. Please RSVP and come over to start contributing to SecureDrop.

The journey continues at Freedom of the Press Foundation

The code we write is the extension of our emotions and thinking. A few months back a twitter thread on Gnome’s account made Anwesha and me think about it once again. I think the most important reply in that thread came from Miguel de Icaza.

The contribution to Free Software happens over 2 forms, for many it helps to solve or support a personal cause. Sometimes it is something we deeply care about (actually the 2 points are not that different). That is why people come back to home from their daily jobs, and then continue contributing upstream till late night. Many jobs now also allow working on upstream Free Software projects as part of the work. The word Open Source helped to create a bridge between businesses and creators. But, we still have to keep fighting for Freedom in various levels in life, even including for the basic human rights.

More than a month back, the Supreme Court of India ruled that privacy is a fundamental right to every Indian citizen. It was a huge win for every privacy advocate, but it was one of the big battles in the whole fight for right to privacy. Even though governments are using public money to develop software infrastructure, almost none of them are Free Software. There is a current campaign happening for having publicly financed software developer for people to be Free Software. No one knows what is going on in the closed source infrastructure, and if people point out the issues, they are getting punished. If you never heard about Aadhaar project in India, feel free to visit this site to learn about how much destruction it is bringing in.

Journalists were the most common people in the movies (in our childhood days) who used to find out all bad things people in power were doing, and at the end of the movie, public used to win with help of court (and sometimes fights between the hero and villains). Things have changed a lot over the years. Now technology enables many to be in a condition to find out the wrongdoings of the state, or private companies. It is much easier to send across that information to the journalists, and we can see how those revelations are helping the world. But, technology also enables the wrong-doers to attack the whistleblowers and the journalists who publish the truth to the people.

At this point if the government can identify the whistleblower, it is too dangerous to be a whistleblower. If we want to find what the state is doing, so that, we, the people, can have control over it, we need to make whistleblowers safe. -- RMS in his talk last year.

Freedom of the Press Foundation is one such organization working to protect and defend journalism, to support journalists and whistleblowers worldwide. One of the major development from the foundation is SecureDrop project. SecureDrop is an open-source whistleblower submission system that media organizations can use to securely accept documents from and communicate with anonymous sources. It was originally created by the late Aaron Swartz. The project also won The Award for Projects of Social Benefit from Free Software Foundation in 2016. This week I joined the Freedom of the Press Foundation as a staff member to help on the SecureDrop and other projects.

As I started writing the post with Why Free Software?, helping the journalists and whistleblowers with Free Software is vital cause I can personally relate to. In the last month, we saw at least 3 journalists killed in India, from 1992, we have the second highest deaths of the journalists due to their work. We also saw the increased death threats to the journalists in India and other parts of the world. The freedom of the press stands as a pillar of the democracy, and we will continue to protect it.