GNU/Linux


Install Gnome Boxes on Kali Linux

Our solution in getting Gnome Boxes to work on Kali Linux (which is a Debian-derived Linux distribution just like Ubuntu) is the following:

First install Gnome Boxes along with all needed virtualization software:

sudo apt-get install -y gnome-boxes qemu-kvm libvirt0 virt-manager bridge-utils;

Then, edit the file /etc/libvirt/qemu.conf to uncomment the following line:

#user = "root"

Finally, restart the host machine and your Gnome Boxes will be ready to use.

Long story

Recently, we were setting up a Kali Linux machine and one of the requirements was to add virtualization support so that the user could execute virtual machines doing.. other stuff. We started by installing gnome-boxes only (hoping that would be enough)

sudo apt-get install -y gnome-boxes;

.. but we got an error:

Boxes cannot access the virtualization backend

Apparently, installing gnome-boxes only, the dependency system did not automatically assume we would need to install an engine to handle the virtual machines, so we had to install the following as well:

sudo apt-get install -y qemu-kvm libvirt0 virt-manager bridge-utils;

After the installation, we tried  to create a new virtual machine but it would fail when we tried to start it. After looking into the logs we found the following useful information:

State: GVIR_DOMAIN_STATE_SHUTOFF

It seems that our user (even if it was root) could not start the QEMU process. To fix this issue we had to modify the file /etc/libvirt/qemu.conf and uncomment the following line:

#user = "root"

from this section

# The user for QEMU processes run by the system instance. It can be
# specified as a user name or as a user id. The qemu driver will try to
# parse this value first as a name and then, if the name doesn't exist,
# as a user id.
#
# Since a sequence of digits is a valid user name, a leading plus sign
# can be used to ensure that a user id will not be interpreted as a user
# name.
#
# Some examples of valid values are:
#
# user = "qemu" # A user named "qemu"
# user = "+0" # Super user (uid=0)
# user = "100" # A user named "100" or a user with uid=100
#
#user = "root"

# The group for QEMU processes run by the system instance. It can be
# specified in a similar way to user.
#group = "root"

After doing this change and restarting the host machine we were able to start and use any virtual machine in Gnome Boxes.

Extra information

In this case, we were using Kali Linux, where people usually operate it using the root account only.
On other installations, like on an Ubuntu installation you would need to handle differently the last step that requires you to edit the /etc/libvirt/qemu.conf file.

Specifically, the best way to handle this issue on a multi-user environment (like Ubuntu) would be to replace the following line:

#group = "root"

with this

group = "kvm"

and then add yourself to the kvm group before restarting the host machine

sudo usermod -a -G kvm $USER;

Doing so, it allows you to enable access to the virtualization services to multiple users of you choice instead of limiting it to one account.

Advertisements

Custom terminator layout with multiple tabs and terminals

The following terminator layout ( Terminator Layout (199 downloads) ) opens 3 different tabs, the first two tabs contain only one terminal each and the third one has 4 terminals in a 2×2 matrix.
Each of these tabs have their own custom name set and following each terminal has its name set to make it easier for the user to recognize the purpose of each one.

Terminator Layout (199 downloads)

After opening these terminals, the configuration file, contains specific commands to be executed by each terminal, allowing you to automate a some trivial part of your day to day operations.
In this example, each terminal will navigate to a specific project or connect via ssh to some server, then it will perform some operation like performing a git pull and finally it will preserve the connection for you by starting a new bash instance to continue using that terminal.

Feel free to edit the layout and create a custom configuration for your tabs / the terminals and the commands.

Installation / Usage

  1. Replace the config ( Terminator Layout (199 downloads) ) file in your home user folder ~/.config/terminator/  with the one we provide
    (In nautilus press Ctrl+H to view hidden files and folders if you cannot find the .config folder)
  2. Open terminator and execute the following:
    terminator -l init;

If you want to create an alias for this command:
Open .bashrc file at your home user folder and add the following

alias my-init="terminator -l init"

For any new terminal in terminator, executing my-init will spawn a new window of terminator that has all the configuration from the file loaded into it.

Contents of Terminator Layout (199 downloads)

[global_config]
[keybindings]
[layouts]
  [[default]]
    [[[child1]]]
      parent = window0
      type = Terminal
    [[[window0]]]
      parent = ""
      type = Window
  [[init]]
    [[[child0]]]
      fullscreen = False
      last_active_window = True
      maximised = True
      order = 0
      parent = ""
      position = 0:26
      size = 1918, 1002
      title = /bin/bash
      type = Window
    [[[child1]]]
      active_page = 0
      labels = www, MA, all other, dev logs, staging logs, live logs
      last_active_term = d3c317d7-964a-4625-96d0-39deb5166072, 93ce7874-059e-4794-b337-7b640654a3d6, db090e6f-07e4-431e-ad86-a8b6cb965b5e, 906a5f4d-a3af-4da8-8385-673b132e7edd, 1b48b3b9-216c-470b-be53-ec1e8c6fdc0b, cb7d737c-a064-4e0e-ad5e-59c47d7bdd3b
      order = 0
      parent = child0
      type = Notebook
    [[[child11]]]
      order = 3
      parent = child1
      position = 956
      ratio = 0.500261643119
      type = HPaned
    [[[child14]]]
      order = 4
      parent = child1
      position = 956
      ratio = 0.500261643119
      type = HPaned
    [[[child17]]]
      order = 5
      parent = child1
      position = 956
      ratio = 0.500261643119
      type = HPaned
    [[[child4]]]
      order = 2
      parent = child1
      position = 956
      ratio = 0.500261643119
      type = HPaned
    [[[child5]]]
      order = 0
      parent = child4
      position = 481
      ratio = 0.500520291363
      type = VPaned
    [[[child8]]]
      order = 1
      parent = child4
      position = 481
      ratio = 0.500520291363
      type = VPaned
    [[[terminal10]]]
      command = cd /vhosts/www.example.com/; git pull; bash
      order = 1
      parent = child8
      profile = default
      title = www.example.com
      type = Terminal
      uuid = db090e6f-07e4-431e-ad86-a8b6cb965b5e
    [[[terminal12]]]
      command = "ssh -t git 'cd vhosts/www.bytefreaks.net/ci_applications/registration_forms/logs/; ll; bash'"
      directory = ""
      order = 0
      parent = child11
      profile = default
      title = WWW dev logs
      type = Terminal
      uuid = 4c08356b-b516-4286-8b6d-ba071f1394f3
    [[[terminal13]]]
      command = "ssh -t git 'cd vhosts/my.bytefreaks.net/symfony/var/logs/; ll; bash'"
      directory = ""
      order = 1
      parent = child11
      profile = default
      title = MA dev logs
      type = Terminal
      uuid = 906a5f4d-a3af-4da8-8385-673b132e7edd
    [[[terminal15]]]
      command = "ssh -t ptl-web3 'cd /data/var/www/vhosts/staging-www.bytefreaks.net/htdocs/ci_applications/registration_forms/logs/; ls -la; bash'"
      order = 0
      parent = child14
      profile = default
      title = WWW staging logs
      type = Terminal
      uuid = 1b48b3b9-216c-470b-be53-ec1e8c6fdc0b
    [[[terminal16]]]
      command = "ssh -t ptl-web3 'cd /data/var/www/vhosts/staging-my.bytefreaks.net/htdocs/symfony/var/logs/; ls -la; bash'"
      order = 1
      parent = child14
      profile = default
      title = MA staging logs
      type = Terminal
      uuid = e26e94cd-855a-44ff-9c67-66b1c03bac56
    [[[terminal18]]]
      command = "ssh -t ptl-web3 'cd /data/var/www/vhosts/www.bytefreaks.net/htdocs/ci_applications/registration_forms/logs/; ls -la; bash'"
      directory = ""
      order = 0
      parent = child17
      profile = default
      title = WWW Live logs
      type = Terminal
      uuid = 70466609-2d01-45d2-84b4-e377b111e540
    [[[terminal19]]]
      command = "ssh -t ptl-web3 'cd /data/var/www/vhosts/my.bytefreaks.net/htdocs/symfony/var/logs/; ls -la; bash'"
      directory = ""
      order = 1
      parent = child17
      profile = default
      title = MA Live logs
      type = Terminal
      uuid = cb7d737c-a064-4e0e-ad5e-59c47d7bdd3b
    [[[terminal2]]]
      command = cd /vhosts/www.bytefreaks.net/; git pull; bash
      order = 0
      parent = child1
      profile = default
      title = www.bytefreaks.net
      type = Terminal
      uuid = d3c317d7-964a-4625-96d0-39deb5166072
    [[[terminal3]]]
      command = cd /vhosts/my.bytefreaks.net/; git pull; bash
      order = 1
      parent = child1
      profile = default
      title = my.bytefreaks.net
      type = Terminal
      uuid = 93ce7874-059e-4794-b337-7b640654a3d6
    [[[terminal6]]]
      command = cd /vhosts/www.michanicos.com/; git pull; bash
      order = 0
      parent = child5
      profile = default
      title = www.michanicos.com
      type = Terminal
      uuid = 2f204209-0c0b-4fab-b883-95f95f5d38e9
    [[[terminal7]]]
      command = cd /vhosts/www.etea.com.cy/; git pull; bash
      order = 1
      parent = child5
      profile = default
      title = www.etea.com.cy
      type = Terminal
      uuid = 6f801914-5225-4e1f-b54c-f48540274614
    [[[terminal9]]]
      command = cd /vhosts/www.ieee.org/; git pull; bash
      order = 0
      parent = child8
      profile = default
      title = www.ieee.org
      type = Terminal
      uuid = 3dbfe3a7-2e25-4e7d-bb02-dc4aeeeda47f
[plugins]
[profiles]
  [[default]]
    background_darkness = 0.8
    cursor_color = "#ffffff"
    foreground_color = "#ffffff"

Cannot update Kali Linux due to invalid signatures

We have this Kali live USB for a few months and it was not used in between. Yesterday, we tried to use it and noticed that we could not perform any updates as we were getting the following error:

The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <[email protected]>

The same stick was used in the past to create a native installation on a PC that had the same issue (because it was also not used for some time).

To fix the issue we had to get a fresh copy of the archive key for Kali repositories and import it into apt.
To do so, our one line solution was the following:

wget -q -O - https://archive.kali.org/archive-key.asc | apt-key add;

To breakdown what the command is all about: we used wget, which is a non-interactive network retriever, to download the PGP public key for the Kali archives. Instead of saving the key as a file to the filesystem, we used the parameters -q and -O so that wget would be quiet and not create any output of its own and print the key on the terminal (using -O). Then we piped the key to apt-key add to add it to the system. After doing so, we were able to properly update the complete system using the following commands:

apt-get update && apt-get upgrade && apt-get dist-upgrade;

Below you will find our console logs:

[email protected]:~# apt-get update && apt-get upgrade && apt-get dist-upgrade
Get:1 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease [30.5 kB]
Err:1 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease
The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <[email protected]>
Fetched 30.5 kB in 2s (10.5 kB/s)
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease: The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <[email protected]>
W: Failed to fetch http://http.kali.org/kali/dists/kali-rolling/InRelease The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <[email protected]>
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists... Done
Building dependency tree 
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree 
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

[email protected]:~# wget -q -O - https://archive.kali.org/archive-key.asc | apt-key add
OK

[email protected]:~# apt-get update && apt-get upgrade && apt-get dist-upgrade
Get:1 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease [30.5 kB]
Get:2 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/main amd64 Packages [16.2 MB]
Get:2 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/main amd64 Packages [16.2 MB] 
Get:3 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/non-free amd64 Packages [166 kB] 
Get:4 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/contrib amd64 Packages [99.0 kB] 
Fetched 451 kB in 1min 6s (6790 B/s) 
Reading package lists... Done
Reading package lists... Done
Building dependency tree 
Reading state information... Done
Calculating upgrade... Done

GNU/Linux: How to give access to a subfolder to a user where the user does not have execute permission over the parent folder

On GNU/Linux, you can traverse a directory if and only if you have execute permission on the whole path that you are going to use to access it. This rule applies a limitation to scenarios where for some reason you want to give execute access to a certain user on a subfolder but you do not want to enable the execute permission on the all the folders in the path.

In order to access the folder theFolder in the path /folderA/folderB/theFolder, if you are on the same level as folderA (or higher) you need to have execute permission both on folderA and folderA/folderB additionally to the permissions needed on theFolder. On another scenario if you are located in the same level as folderB (and you have execute rights to it) even if you do not have the execute rights to folder folderA you would still be able to access theFolder as your whole path (which is a relative path in this scenario) skips folderA. This feature is due to the fact that in GNU/Linux that the path that you use to access a folder determines your access constraints. In cases where the user does not have execute access to the whole path, creating symbolic links for them will not help you give them access. The kernel will still go through the access rights of the whole path that the symlink describes and it will act accordingly.

A hack-ish solution around this issue is to use mount to remount a part of the file hierarchy somewhere else using the bind parameter. For example: if we needed to give access to a user to the folder theFolder that resides in /folderA/folderB/theFolder without enabling execute rights on folderA nor /folderA/folderB we could execute the following command in a folder where that user already has execute access in (for example in the user’s home folder).

sudo mount --bind /folderA/folderB/theFolder finallyTheFolder;

Notes:

  • This solution circumvents security, be sure to think things through before implementing it
  • This solution ‘escapes’ normal good practices so it could lead to software bugs on your behalf
  • The bind will not persist after a reboot
  • To make this change permanent, you will need to add a configuration line in /etc/fstab
  • If the directory that you wish to bind contains mounted file systems, these file systems will not be transferred to the target. The mount points will appear as empty directories.

Using TeamViewer tar package on Ubuntu

Recently, we needed to start TeamViewer on an Ubuntu GNU/Linux machine where we did not want to install it.
To do so, we used the 64bit tar package from the TeamViewer Linux download page.

After downloading the package and extracting its content, we realised that we could not start TeamViewer (./teamviewer) as is.
In order to troubleshoot, we used a terminal and executed the check libraries functionality (./tv-setup checklibs;) from the archive folder that gave us some missing dependencies:

./tv-setup checklibs

    -=-   TeamViewer tar.xz check   -=-     

  In order to use the tar.xz version of TeamViewer,
  you have to make sure that the necessary libraries are installed.

    Writing raw output to /home/xeirwn/Downloads/teamviewer_13.1.3026_amd64/teamviewer/logfiles/DependencyCheck.log

 Analyzing dependencies ...           
    libQt5Core.so.5 => not found
    libQt5DBus.so.5 => not found
    libQt5Gui.so.5 => not found
    libQt5Network.so.5 => not found
    libQt5Qml.so.5 => not found
    libQt5Quick.so.5 => not found
    libQt5WebKit.so.5 => not found
    libQt5WebKitWidgets.so.5 => not found
    libQt5Widgets.so.5 => not found
    libQt5X11Extras.so.5 => not found

    The libraries listed above seem to be missing.
    Please find and install the corresponding packages.
    Then, run this command again.

    QtQuickControls seems to be missing

    The following command may be helpful:
      apt-get install libdbus-1-3 libqt5gui5 libqt5widgets5 libqt5qml5 libqt5quick5 libqt5webkit5 libqt5x11extras5 qml-module-qtquick2 qml-module-qtquick-controls qml-module-qtquick-dialogs qml-module-qtquick-window2 qml-module-qtquick-layouts;

Solution: Following the instructions we executed the following:

sudo apt-get install libdbus-1-3 libqt5gui5 libqt5widgets5 libqt5qml5 libqt5quick5 libqt5webkit5 libqt5x11extras5 qml-module-qtquick2 qml-module-qtquick-controls qml-module-qtquick-dialogs qml-module-qtquick-window2 qml-module-qtquick-layouts;

After the installation of the libraries, we executed once more the check libraries functionality (./tv-setup checklibs;)  where we got the message that everything seem to be OK.

 ./tv-setup checklibs

    -=-   TeamViewer tar.xz check   -=-     

  In order to use the tar.xz version of TeamViewer,
  you have to make sure that the necessary libraries are installed.

    Writing raw output to /home/xeirwn/Downloads/teamviewer_13.1.3026_amd64/teamviewer/logfiles/DependencyCheck.log

 Analyzing dependencies ...           

    All library dependencies (*.so) seem to be satisfied!

    QtQuickControls seems to be installed

Trying to start the (./teamviewer)  application did not gave an error but it would not start again.
It appeared that there was a service running which would not allow the GUI to show up.
To avoid too much fuss, we restarted the machine and tried (./teamviewer)  once more, this time with success.
So after installing the libraries and restarting the machine, we were able to start TeamViewer on our Ubuntu machine without installing it.


Fedora GNU/Linux : Disable USB Storage Devices

There is this machine that runs Fedora GNU/Linux, for which its owners asked us to block all USB Storage Devices without affecting other peripheral devices like keyboards and mice. The reason for that was to prevent unlawful data leakage that the users of that machine could do.

On Linux there is a kernel module named usb_storage that can be found at /lib/modules/$KERNEL_VERSION/kernel/drivers/usb/storage/usb-storage.ko.xz (to get the kernel version, execute uname -r;) which operates as the USB Mass Storage driver for Linux.

Apparently, we just needed to block the usb_storage module.  Initially, we tried to block the module by using the /etc/modprobe.d/blacklist.conf file but with no success. We failed to blacklist the module using the following commands (we were not sure which of the two names are correct, so we tried both, one at a time. It appears that both can be correct..):
echo -e "usb_storage\n" | sudo tee -a /etc/modprobe.d/blacklist.conf;
echo -e "usb-storage\n" | sudo tee -a /etc/modprobe.d/blacklist.conf;

After creating/updating the blacklist.conf file we restarted the machine as the module does not get loaded on boot automatically, it only gets loaded when needed. Unfortunately, as we mentioned before, these attempts led to no solution as we were still able to use USB storage devices even after creating the blacklist.conf file.
Since this method failed, we had to turn our heads towards a different solution, that due to its nature, it can be considered a hack.

Solution

What we did was to create a new configuration file in /etc/modprobe.d/ that would prevent usb_storage from being loaded by redirecting any requests to load the specific module to the /bin/true application.

echo "install usb_storage /bin/true" >> /etc/modprobe.d/disable-usb-storage.conf;
# Or the following (both names usb_storage and usb-storage seem to work)
# echo "install usb-storage /bin/true" >> /etc/modprobe.d/disable-usb-storage.conf;

Then, we had to make sure that the module was not already loaded. To see if the usb_storage module was already loaded we executed:

lsmod | grep -i usb_storage;

When lsmod | grep -i usb_storage; did not return any results, then it meant we were done! Since it was not in the list, it meant that the module was not loaded and so the next time someone tried to use a USB mass storage device they would not be able to load the module.

In cases were we got a line back (and thus the module was already loaded), then we needed to unload it manually or restart the machine. To avoid rebooting the machine we used modprobe to unload the usb_storage module.

modprobe -r usb_storage;

Some times, we would get the following error: modprobe: FATAL: Module usb_storage is in use.. This error meant that some other kernel module was using usb_storage and would not allow us to unload it. Using lsmod | grep -i usb_storage; we would get back a line like the following: usb_storage 73728 1 uas. The last column is a comma separated list of kernel modules that use usb_storage and we would need to unload them as well (replacing commas with space characters). Since we had only one dependency, our command became like the one below:

modprobe -r uas usb_storage;

And we were done!

To Re-enable USB mass storage devices (revert)

That is the easy part, to re-enable access to the USB mass storage devices, all we had to do was delete the configuration file:

rm /etc/modprobe.d/disable-usb-storage.conf;

Of course, to block them again, the we would have to follow the steps in the above solution.


Fedora GNU/Linux: Disable/Stop or Enable/Start Bluetooth service

There was this Fedora box for which we were asked to disable most of the methods it had available for communicating with the outside world.
One of the features of the box that we decided to block was its Bluetooth device.
To make our life easy, and since the users would not have admin rights, we decided to simply stop and disable the Bluetooth service on the box and be over with it!

The way we stopped and disabled the Bluetooth service was with the following two devices.

#Stop Bluetooth service that is currently executing
systemctl stop bluetooth;
#Prevent Bluetooth service from starting after a reboot
systemctl disable bluetooth;

Once you disable the service and stop it, you will notice that on the GUI of the Gnome settings application it still shows the basic menu for the Bluetooth device.
That should not worry you though because if you enter the Bluetooth configuration tab you will notice that the user will not be able to turn the device on and make use of it.

Revert changes and re-enable / re-start the Bluetooth service:

In order to restore the Bluetooth service back to normal (to enable it and start it), just execute the following two commands:

#Start the Bluetooth service right now
systemctl start bluetooth;
#Make sure that Bluetooth service will start after each system restart
systemctl enable bluetooth;


GNU/Linux Fedora 27: Prevent Network Manager from restarting after reboot 1

Recently we were working on a Fedora 27 GNU/Linux box where we needed to completely disable the Network Manager.
Initially, we just stopped the NetworkManager service and then disabled it thinking that it would be enough.
To our surprise after we rebooted the box, we noticed that the Network Manager was active again!

After some research we found out that another service called NetworkManager-wait-online was starting the NetworkManager as some sort of recovery mechanism.
So, in order to permanently block NetworkManager from starting on boot, we disabled NetworkManager-wait-online as well.

In the end our solution to disable the NetworkManager service came down to executing the following commands as root (or using sudo):

systemctl stop NetworkManager;
systemctl stop NetworkManager-wait-online;

systemctl disable NetworkManager;
systemctl disable NetworkManager-wait-online;


Ubuntu: install / start/stop enable/disable ssh server

OpenSSH is a freely available version of the Secure Shell (SSH) protocol family of tools for remotely controlling, or transferring files between, computers.

Install SSH server

To install the openssh-server on an Ubuntu, you need execute the following command as root or using sudo:

apt-get install openssh-server -y;

Disable SSH server

To disable the ssh service, execute the following command as root or using sudo:

systemctl disable ssh;

Enable SSH server

To enable the ssh service, execute the following command as root or using sudo:

systemctl enable ssh;

Stop SSH server

To stop (or deactivate) the ssh service, execute the following command as root or using sudo:

systemctl stop ssh;

Start SSH server

To start (or activate) the ssh service, execute the following command as root or using sudo:

systemctl start ssh;

Status of SSH server

To check the status of the ssh service, execute the following command as root or using sudo:

systemctl status ssh;

CONCEPTS

In a nutshell:

  • enabled is a service that is configured to start when the system boots
  • disabled is a service that is configured to not start when the system boots
  • active is a service that is currently running
  • inactive is a service that is currently stopped and may be disabled, but it can be started and become active

In much more detail:

systemd provides a dependency system between various entities called “units” of 12 different types. Units encapsulate various objects that are relevant for system boot-up and maintenance. The majority of units are configured in unit configuration files, whose syntax and basic set of options is described in systemd.unit(5), however some are created automatically from other configuration, dynamically from system state or programmatically at runtime. Units may be “active” (meaning started, bound, plugged in, …, depending on the unit type, see below), or “inactive” (meaning stopped, unbound, unplugged, …), as well as in the process of being activated or deactivated, i.e. between the two states (these states are called “activating”, “deactivating”). A special “failed” state is available as well, which is very similar to “inactive” and is entered when the service failed in some way (process returned error code on exit, or crashed, or an operation timed out). If this state is entered, the cause will be logged, for later reference. Note that the various unit types may have a number of additional substates, which are mapped to the five generalized unit states described here.
— From man systemd