Niklas Anderson's Blog


This blog is also available to Tor users here: http://writeas7pm7rcdqg.onion/niklasanderson

I used to have my blog hosted by Netlify running Jekyll. But I found it all cumbersome and annoying, so I have swapped to While does not offer all the features I would like, it is more or less in line with my expectations of privacy. It is also simple enough for my simple mind.

I apologize if you have found this blog. I occasionally write here, but I do not accept any responsibility for any damage caused by me you reading what is here.

I have these categories which you can sort my posts by:

#MyIgnorantViews #MeaninglessAphorisms #TechnoPosts #IsThisCreative


Proton by Valve has greatly increased the number of playable games on Linux, but almost all games running in proton break when Steam is run from firejail.

A couple fixes can be introduced to allow Proton games to run, the errors referred to here come from running Steam from a terminal and watching the feed (just type "steam" into a terminal and hit 'Enter').

#/usr/bin/env: 'python3': Permission denied

Edit /etc/firejail/steam.profile and add the line:

noblacklist /usr/bin/python*


ERROR: home '/home/user/.local/share/Steam/ubuntu1232/' from LDPRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored

Edit /etc/firejail/steam.profile and comment out "seccomp" with "#", like so:


This will expose a lot of kernel surface area, reducing the effectiveness of Firejail in protecting the remainder of the operating system from a compromised steam client or a game launched within it. You have to decide if it is worth the games you are playing.

Also consider not playing games on a machine that needs security, you can always buy a chromebook for banking or shopping.

A more open seccomp filter could be generated by running strace on steam, but I am too lazy to do this myself. I once tried, but the syntax of Firejail was undocumented and a lot of syscalls I tried to add to a whitelist from strace were considered invalid to firejail.

Additional problems can sometimes be fixed by removing the steam overlay for a game.

Hope this helps someone; Glory to Linux


As someone who has done a fair amount of work in the Unix command-line world, it can be difficult to understand how others might struggle with a tool such as OpenSSH. SSH is loved amongst those are in the field, it is simple to use, simple to extend, and simple to secure. This will be a very simple getting started post, which explains the fundamentals of the SSH client while directing the reader to try connecting to public Dungeon Crawl Soup game servers to start off.

SSH stands for "Secure SHell", and is a protocol that enables remote access. It allows you to interact with a remote machine as though you were sitting right in front of it, and while it is generally used for issuing commands via the terminal, it can actually be used to pull graphical windows from on machines X11 desktop if desired, or even be used to open a SOCKS proxy. There is a great deal that can be done with SSH, and given its Unix qualities, its power is extensible by other applications known to the user (I'm thinking of TMUX, SCP, etc).

While ultimately supplanting the old, unencrypted Telnet application as a secure alternative, it is important to remember that a server accepting SSH connections cannot be presumed secure just because it uses SSH. This tutorial is not intended to expand on how to harden SSH or the rest of the machine.

SSH is a protocol supported by many applications, the two types of applications being either a client or server. The two most popular clients being OpenSSH developed by the OpenBSD development group and available on UNIX platforms, and the other being PUTTY developed primarily by Simon Tatham for Windows. There are others, and PUTTY is limited in feature set by comparison so it will need additional programs to match the power of OpenSSH.

Almost all Linux Distros have OpenSSH installed by default, and many will atleast prompt to install SSHd, the server side counterpart to the OpenSSH client.

To begin with, you may not have a server to connect to. In that case, you can try connecting to a game server, such as the public Dungeon Crawl Soup servers with SSH availability. An example would be the server.

Not all servers support SSH, but those who do make it very easy, and all instructions are available at the link above. In the case of, you type the following into your terminal


When prompted for the password, enter "joshua".

Simple, but you may already be confused if you haven't read the Crawl Online tutorial. "joshua" is an arbitrary ssh account made available to the public. When you connect as Joshua, there may be dozens of other open sessions by other users on that same account. You do not have the ability to change this user account, and you will be suddenly trapped in a specific application, that being the Dungeon Crawl Soup Game. Both the public username and the entrapment of the user in a specific application is not typical.

The ssh username@remote_host command can use either the domain name of the server or the IP.

You are now issuing commands to a remote terminal. Despite the simplicity of the terminal, you may notice some lag between your input and its appearance on screen. Crawl has its controls largely based on Vim, so you can practice those skills here too.

To extend your exposure to SSH in general, you may need to rent a Virtual Private Server, or have some hardware running Unix available to you within your network (another PC, Raspberry Pi, etc.).

I'd prefer to refer to DigitalOcean's SSH tutorial for further server side work. I thought recommending the Crawl servers was interesting "getting started" idea that I haven't seen.


GNU/LINUX is popular amongst paranoid types due to the audit-able nature of its codebase (or at least most of it).

Many, however, are ultimately misled into thinking that mainstream distributions of GNU/Linux are more secure than windows out of the box. If you scrutinize a newly installed machine, you will find that this is not the case. In fact, almost all distributions start off without a host firewall: That means the machine is open to all incoming connections within its network!

Linux machines are generally unsecured by default. On first boot, most distros do not even have firewalls running by default: they are open to the world. This ultimately implies that Windows 10 is more hardened out of the box than nearly every GNU/Linux. But if a user is willing to experiment and tinker, a Linux machine can be made to compete with Windows in a serious way. Linux machines are, after all, a prime choice for enterprise servers, but are typically maintained by experienced admins.

I'll lay out a number of tips in this post for how to harden one particular distribution of GNU/Linux: Debian. Debian is maintained by the non-profit Debian Project (also: http://sejnfjrq6szgca7v.onion/). It is used as the basis for non-privacy oriented distributions like Ubuntu, but also for security and privacy focused distributions such as the ephemeral operating system Tails, an anonymizing operating system made to be run as a virtual machine called Whonix, etc. There are many more, but I will leave it there.

Debian has one strong benefit: its default software is free software/open sources open license/public. And the software made available via its package manager is verified via a reproducible builds which prevent developers from offering compiled software that is different than the source code they release publicly. Nearly every package offered by the Debian project is complied multiple times by multiple people, so that the hashes of each compilation can by referenced against the package maintainers version to verify he/she has not secretly modified the package. The Debian infrastructure has removed as much trust as possible between the user and the developer, and has thus weakened a serious avenue of attack (an attack made all the more real after the Snowden revelations).

I will start by offering a couple guides that are already available elsewhere:

The AnonGuide is one of the best available starting points for a hardened Debian. It walks you through verifying that your Debian installation file is legitimate, directing debian to update over Tor to official Debian .onion servers, use Whonix within a virtual box, harden your kernels network stack, and even use a keyfile when encrypting your hardrive (the keyfile thing is next level paranoid, but losing that keyfile is losing your data).

The securing Debian manual, the age shows in this own. Some of its suggested tools no longer exist, and there are more that could be added.

Remember that the goal is to make attacks expensive to carry, not impossible. I am assuming the user is relatively new to using Debian. So many readers will not find this helpful.

Now for my tips:

  1. Use disk encryption, particularly with laptops.

  2. In the installation of Debian, you will be offer the opportunity tor partition the drive use LVM with disk encryption.

    Do so, and utilize a strong passphrase

  3. Put strong passwords on your root user and any sudoer/sudo enabled user

    You want to reduce the likelihood of malware being executed by root. An easy way to do so is to make root passwords too strong for malware to guess.

  4. Create separate users for less trustworthy applications

  5. Separate users based on the trustworthiness of applications. Keeping essential files and software away from

  6. Start by activating some kind of firewall and setting it to blocking incoming connections. This will allow your machine to initiate connections, but not accept unsolicited.

  7. If you're a newbie, try UFW (uncomplicated firewall):

    sudo apt-get install ufw

    sudo ufw default deny incoming

    Also (from anondistro):

    sudo nano /etc/ufw/before.rules


    Now search for "icmp"

    Add "#" before each line under "# ok icmp codes" until the line "# allow dhcp client to work"

    sudo ufw enable

  8. Configure Debian to update over TOR with apt-transport tor

  9. When Debian fetches software via its package manager, apt, it uses a locally available public key to verify/authenticate the packages it receives to ensure only legitimate software is installed. A bad guy, including one who had taken control of the server you update from, cannot tamper with the software unless he has the private key used to sign the software. The problem is, however, that most servers do not provide any encryption. You can see this when your run apt-get update and see "http://arbitrary-mirrorserver". That means a bad guy can still see what you're installing and utilize that information in an attack.

    The Debian project thus responded with quite a leap in privacy by providing the apt-transport-tor utility, which forces apt to anonymize its traffic, then by providing official .onion servers in order to prevent the apt traffic from leaving the tor network.

    sudo apt-get install apt-transport-tor

    sudo nano /etc/apt/sources.list

    Modify to match the following:

    deb tor+http://vwakviie2ienjx6t.onion/debian stretch main

    deb tor+http://vwakviie2ienjx6t.onion/debian stretch-updates main

    deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security stretch/updates main

    You may add "tor+" to any repo's address you wish. But the traffic will leave the tor network if it is not .onion.

  10. Utilize sandboxing

  11. Sandboxing constrains running programs under default or user written rules. These rules can vary from file and directory access rules to network and window manager rules

    Two popular sandboxing solutions on linux are Apparmor and Firejail. Both are easy to use, and are widely available in distros.

    You also have the option of installing applications through Flatpak

    I have another post on firejailing steam, which can be used as a guide for how to utilize private directories within firejail. A use feature if that application is taking in files and remote code from the outside world.

    It's important to note that the X11 problem, wherein any application listening on X11 can see anything other applications receive or send through the GUI, can be mitigated by firejail.

    Firejail offers a --x11 option that can designate an alternative display server such as xephyr. Adding "--x11=xephyr" will pick up its configuration from /etc/firejail/firejail.conf and open up a strange, unadjustable window on your screen containing the sandboxed software. You will notice that the xephyr window is effectively its own desktop. A window manager can be run within the xephyr X11 sandbox window, meaning the sandboxed programs can be resized within the statically sized xephyr window.

    If you read that last paragraph without trying it yourself, you will probably not have understood a word of it. Try it out, and you'll see.


It's a good idea to sandbox steam.

Many online games offer no protection against multiplayer and content, meaning a server can easily inject malicious assets into a client. It's also the case that most games use unencrypted and unauthenticated connections between the client and server, as it would increase latency, but nonetheless leave the connection vulnerable to malicious injections by a man-in-the-middle. Without encryption, the software itself is entirely responsible with resisting malicious attack (how many game developers have time to worry about that?).

Some games also run their own installers, which fail to authenticate what they download and install.

For windows users, Steam has resisted allowing itself to be installed or run in popular sandboxing solutions like Sandboxie, limiting windows users to creating a separate user account in order to properly isolate steam from more essential software and files.

GNU/Linux users are in luck, however, since solutions like Firejail are easy to apply with little overhead and are available in the repositories of most distributions. This will allow the steam to run in an environment that restricts its ability to read and write to existing files used by other software or the OS' kernel, as well as its ability to execute code outside of its sandbox.

Keep that proprietary crap out of my $HOME!

Firejail has a preinstalled steam.profile found in /etc/firejail/ which applies some restrictions to the steam client and the software it runs. But it should be made more restrictive through the application of a private $HOME directory. I will show you how to install and apply the firejail with this modification.

It should be noted that a private Home directory will mean that currently installed games will have to be moved into that directory in order for steam to find them. This ultimately keeps all of steam and its related software and files together in one folder making system management and hygiene easier.

I am also assuming you know how to install steam or have it already installed, and that you know how to open a terminal and traverse directories comfortably.

There is also an older blog post on how to do this by Joris van Rantwijk, but it appears out of date and includes unnecessary steps such as extracting steam.deb then running ./steam inside the private directory under firejail. You do not need to do this, as you can download the steam installer normally from your repository, and steam will install itself inside a sandbox if you have the profile applied. If you run steam and allow it to update and configure itself before applying the modified firejail profile you will only be creating unneeded files in your actual Home directory.

You can apply these steps in nearly any distro, but I am running in Debian.

Lets begin by installing firejail:

sudo apt install firejail

Let's read a little about firejail. Please read the whole summary in the man page if firejail is new to you.

man firejail

Firejail is a SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applica tions using Linux namespaces, seccomp-bpf and Linux capabilities. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table. Firejail can work in a SELinux or AppArmor environment, and it is integrated with Linux Control Groups.

The firecfg command is also now available as part of firejail. When it is run, it will apply firejail rules to all compatible software firejail has profiles for.

man firecfg

... run 'sudo firecfg' after installing Firejail software. The same command should also be run after installing new programs. If the program is supported by Firejail, the symbolic link in /usr/local/bin will be created. For a full list of programs supported by default run 'cat /usr/lib/firejail/firecfg.config'.

If you do not want some piece of software to run under firejail, you can either change the name of its profile in "/etc/firejail/$SOFTWARE.profile" or comment the software out in "/usr/lib/firejail/firecfg.config". If you only want steam to run firejail, comment out or delete all other applications in firecfg.cfg (again, # prevents firecfg from reading the remainder of that line).

You should take a look at the firejail profile that firecfg will apply to steam (and your other applications):

cat /etc/firejail/steam.profile

You will notice that there are optional settings commented out in this profile (the # stops firejail from reading the line). You can play with these later, but for now we will focus on the private home directory.

Let's first run firecfg and apply firejail system wide:

sudo firecfg

Firejail will now be applied to steam and all other software. Firecfg will list what profiles were applied when the command is run.

If firecfg fails to find a program you know has a .profile available, you can employ a number of simple hacks to get the software to run under firejail: such as creating desktop launchers that include "firejail $arbitraryProgram", or by adding your own symbolic links.

To make it impossible for steam and your games to see your Home directory and its contents, you will want to designate an arbitrary folder as its Home directory in firejail.

You can name it what you like, but I will call it steamJail from now on. You may put this directory wherever you like, and steam or any games installed by and running out of steam will be placed here without the ability to traverse upwards in the directory from this folder, making your personal files safer.

The following command will create a directory/folder in the working/current directory. Make sure to run this where you want the steamJail folder to exist:

mkdir steamJail

Let's do a test run of steam with "firejail --private=/parentDirectories/steamJail steam" in the command. Remember that "/parentDirectories/" is a placeholder for the where your version of steamJail is. You can use the "pwd" command from with steamJail to find your directory chain for this command.

It should being updating itself in that new Home directory, steam is generating and populating a .steam directory hidden inside your home directory. If you have run steam before you should already have one generated in your original home directory (you can move that original .steam directory to your private ./steamJail so steam will not have to do everything over again). As far as the steam executable knows, your user account has never ran steam before since it finds no evidence of an earlier configuration.

firejail —private=/parentDirectories/steamJail steam

Note that you can technically have two separate applications share a single private directory if you'd like.

You can check if a program is running in firejail with:

firejail —list

You can also use the separate firejail-tools to get access to a gui that can visualize what is going on in your sandboxes. This can be useful if you want reassurance that your steam games are running in the same sandbox as Steam.

Go ahead and test the private Home directory setting by right clicking on a game you have installed and looking at its local files (steam throws an error about not finding it, before finding it). Or, you can go into Settings -> Downloads -> STEAM LIBRARY FOLDERS -> Add Library Folder then taking a look at what steam can see.

Be aware that the steam.profile mounts folders such as /dev/ and /etc/ as readonly so steam can run properly without risking root file system writes. You may set these as private as well by editing steam.profile and removing the commenting # by the respective command, but this could cause errors with some of the games you are trying play.

If you want steam to run within this directory permanently, which is likely the case if you are reading this tutorial, you will have to edit the steam.profile and make this command run as part of its profile.

You can use whatever command line editor you want, but I'll run nano for those who have less experience.

sudo nano /etc/firejail/steam.profile

Below the following line in steam.profile:

include /etc/firejail/globals.local

Add a modified version of your previous firejail command (recall that "/parentDirectories/" is a placeholder in this example):

private /parentDirectories/steamJail

From now on, steam will run within this private folder with its processes contained by firejail. You can see into this directory from the outside normally, but steam is limited in its ability to see beyond it.

If you already have games installed outside this directory, you can scavenge the files together and move them yourself. Or you can simply delete them for a reinstall and hope steam cloud saves is holding on to your save files.

You may also delete all remnants of steam from your actual Home directory, this includes hidden files such as /home/user/.steam or anything a game may have added. You should also consider applying this sandboxing method to other software, like your browser or email client.