Simplify the safeguarding of programs with Firetools

Useful Toolbox

If you click Firetools in the Firetools window or select the Tools item from the context menu, a window appear, which lists all the sandboxes currently running with some relevant additional information. In Figure 3, Firefox is running under the process ID 19090, is taking up 0.20 percent of the processor time, and is hogging 268,296 kibibytes of central memory. The program was started by Firetools using the firejail firefox command (Command ) and is not currently sending any data (TX(KB/sec) ) or receiving any (RX(KB/sec) ). Firetools continuously updates the data; however, in the test, the RX/TX counter didn't work and was constantly at 0 .

Figure 3: The Firetools process analysis all the programs launched with Firetools. A terminal and Firefox are each running in a separate sandbox.

You will receive detailed information by clicking a process ID (Figure 4). The display shows the processor load and the memory usage in the last few minutes for each process in two curves. Unusual fluctuations may indicate attack attempts or a rampage by the process. To kill the process, click Shutdown . The Process Tree indicates which sub-processes the locked application has started. These processes run in the same sandbox. You can open a shell in this same sandbox via Join . This is useful for analyzing the processes in the sandbox, ending them in a controlled manner.

Figure 4: The statistics provide information about resource requirements for the monitored process.

The analysis window contains the items Seccomp and Capabilities . If the hexadecimal number behind Capabilities is not composed entirely of zeros, the process is allowed to access one or more system functions. To determine the specific functions, click the hexadecimal number (Figure 5). If Seccomp is set to enabled , the system prohibits the process from executing certain security-critical actions. This includes not being allowed to start programs with root privileges (SUID).

Figure 5: After clicking Capabilities, Firetools also displays all system functions prohibited by Firejail.

If you click enabled , you will get a list of all prohibited system functions and actions (Figure 6). To specifically prohibit or allow one of the functions, you need to give Firejail the corresponding parameter, which a previous article already covered in detail [1]. Firetools itself does not provide any options for this at the moment.

Figure 6: The Seccomp filter prohibits the process from mounting filesystems, among other things.

You can open DNS settings that are currently applicable on the system via the DNS entry; clicking Home returns you to the overview. All Firejail sandboxes, even those that you started in a separate terminal not in Firetools, always appear in the overview.

Conclusions

The fact that the development of Firetools only started in the spring of 2015 is reflected not least in the pretty small functionality. The main window forgetting all changes upon quitting is particularly annoying – it degrades the tool in its current form to little more than an object to look at. If you need to use a specific function in Firejail, you also need to attach the corresponding parameters to the program call. The constantly updated statistics in the tools window at least provide a decent and quick overview of the current processes. Firetools will definitely be a useful tool for using Firejail if the developers correct the issues described soon.