Skip to content

Instantly share code, notes, and snippets.

Last active February 9, 2024 15:04
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save dante-robinson/3a2178e43009c8267ac02387633ff8ca to your computer and use it in GitHub Desktop.
Save dante-robinson/3a2178e43009c8267ac02387633ff8ca to your computer and use it in GitHub Desktop.

Linux Security Guide

Table of Contents

Mandatory Access Control
Root Tweaks
Extra Tweaks
Password Locking Bootloader
Best Practices

You can find an easier to read version of this guide on my blog here -


We are going to start with some sysctl configuration. These are basically tunable kernel settings that can be set temporarily or hardcoded which is what we are going to do here by adding the commands to .conf files.

First things first we want to delete the default set sysctl configuration we can do that by running this command

sudo rm /usr/lib/sysctl.d/50-default.conf

In the /etc/sysctl.d directory we are going to create a file named kptr_restrict.conf which we can do by running

sudo touch /etc/sysctl.d/kptr_restrict.conf

however for the sake of keeping this guide somewhat shorter and a lot quicker to implement I am going to be using nano to create the file and save it in the directory. So we can open the file by running

sudo nano /etc/sysctl.d/kptr_restrict.conf

and then inside the file we are going to paste


Then we can press Control + X and then enter to save the file in that location. I'm not going to keep reiterating over this all the way through the guide but that's how we'll be saving the files using nano here on out unless stated otherwise.

I also mentioned earlier you can set these temporarily I'm not gonna state this for all of the sysctl changes but you can run

sysctl -w kernel.kptr_restrict=2

this will temporarily set the change on your system if you would like to set the others temporarily just remove the kernel.kptr_restrict=2 part with the other configurations.

So what does that even do? This setting will attempt to prevent any possible kernel leaks such as dmesg or /proc/kallsyms. These pointers can be very useful for a kernel exploit. The =2 will print all kernel pointers regardless of privileges (such as root) as 0s and =1 one will just print it that way for the user.

Now we can run nano again to create dmesg_restrict.conf

sudo nano /etc/sysctl.d/dmesg_restrict.conf

and inside we can paste


This will prevent users from accessing the kernel logs which can be useful to gain information such as kernel pointers.

Next create the ldisc_autoload.conf file

sudo nano /etc/sysctl.d/ldisc_autoload.conf

and inside we can add


This will Automatically loading TTY Line Disciplines. If you are unfamiliar with TTY line discipline it processes all incoming and outgoing characters to and from a tty device.

Next create the protected_fifos file

sudo nano /etc/sysctl.d/protected_fifos.conf

and add


This will avoid unintentional writes to an attacker-controlled FIFO, where a program may have expected to create a regular file.

Next create the protected_regular.conf file

sudo nano /etc/sysctl.d/protected_regular.conf

and add


This protection is similar to protected_fifos, but it avoids writing to an attacker-controlled regular file, where the program may have expected to create one.

Next create the protected_hardlinks.conf file

sudo nano /etc/sysctl.d/protected_hardlinks.conf

and add


This will make sure hardlinks cannot be created by users if they don't already own the source file, or do not have read/write access to it.

Next create the protected_symlinks.conf file

sudo nano /etc/sysctl.d/protected_symlinks.conf

and add


Symlinks will now only be permitted to be followed only when outside a sticky world-writable directory, when the uid of the symlink and follower match, or when the directory owner matches the symlink’s owner.

Next create the suid_dumpable.conf file

sudo nano /etc/sysctl.d/suid_dumpable.conf

and add


Any process which has changed privilege levels or is execute only will not be dumped.

Next create the core_uses_pid.conf file

sudo nano /etc/sysctl.d/core_uses_pid.conf

and add


By setting core_uses_pid to 1, the coredump filename becomes core.PID. If core_pattern does not include “%p” (by default it doesn't) and core_uses_pid is set, then .PID will be appended to the filename.

Next create the ctrl-alt-del.conf file

sudo nano /etc/sysctl.d/ctrl-alt-del.conf

and add


This will cause the system to prevent restarting when ctrl + alt + del is pressed. Usually Windows users do this.

Next create the modules_disabled.conf file

sudo nano /etc/sysctl.d/perf_event_paranoid.conf

and add


This makes it so only root can access perf events

Next create the randomize_va_space.conf file

sudo nano /etc/sysctl.d/randomize_va_space.conf

and add


This enables heap randomization.

Next create the unprivileged_bpf_disabled.conf file

sudo nano /etc/sysctl.d/unprivileged_bpf_disabled.conf

and add


This will disable all unprivileged calls to bpf().

Next create the ptrace_scope.conf file

sudo nano /etc/sysctl.d/ptrace_scope.conf

and add


NOTE* THIS WILL BREAK SOME WINE/PROTON GAMES FROM LAUNCHING. This makes only processes with the CAP_SYS_PTRACE flag are able to use ptrace. Ptrace is a system call that allows the program to change and inspect a running process which would allow an attacker to see and potentially compromise running programs.

Next create the kexec.conf file

sudo nano /etc/sysctl.d/kexec.conf

and add


This will disable kexec which can be used to replace the current running kernel.

Next add the sysrq.conf file

sudo nano /etc/sysctl.d/sysrq.conf

and add


This will disable the SysRq key which exposes tons of potentially dangerous debugging functionality to unprivileged, local users.

next create the unprivileged_users_clone.conf file

sudo nano /etc/sysctl.d/unprivileged_users_clone.conf

and add


This will disable unprivileged user namespaces. User namespaces can allow for privilege escalation and this will restrict them to being root only. Some sandboxing programs such as bubblewrap may break but can usually be fixed by making sandbox binaries setuid.

You should consider running a Linux Hardened version of the kernel however keep in mind you will lose things like bluetooth support by doing this. If this is something you are interested in running to secure your kernel even further you can read your official documentation from your distro. For most it will just require downloading linux-hardened and linux-hardened-headers and then if you use GRUB you will need to rebuild it with grub-mkconfig. If you wanted to take your security even further you can compile your kernel from source which will give you unique kernel keys. You can also check out GRSecurity for extra patches however they do cost money you can check out there page here -

Bootloader Parameters

Now we will move into the Bootloader parameters I would recommend using GRUB as your bootloader however either GRUB, Syslinux or systemd-boot will work for these.

If you are using GRUB you edit your boot parameters running

sudo nano /etc/default/grub

and you can add the following parameters to the end of GRUB_CMDLINE_LINUX_DEFAULT=""

If you are using Syslinux

sudo nano /boot/syslinux/syslinux.cfg

and you can apply your parameters to the APPEND line.

If you are using Systemd-boot

sudo nano /boot/loader/entries/arch.conf

and you can add them to the end of the options line. If you cannot edit the parameters from the boot menu, you may need to edit /boot/loader/loader.conf and add editor 1 to enable editing. If on another distro it probably won't be called arch.conf you can do

ls /boot/loader/entries/

to see what the configuration file is called.

Next you need to figure out what you want to run AppArmor or SELinux. SELinux is more secure in my opinion but can be a lot more work to setup for your distro compared to AppArmor.


AppArmor -

For App Armor you should just need to install the apparmor package for Arch that would be

sudo pacman -S apparmor

and enable the service with

sudo systemctl enable apparmor.service

on Debian based Distros (Ubuntu, Mint, Kali, etc)

sudo apt-get install apparmor apparmor-utils auditd

on SUSE based distros (OpenSUSE, idk anymore...)

zypper install libapparmor apparmor-profiles apparmor-utils apparmor-parser yast2-apparmor

for Void Linux

sudo xbps-install apparmor

on RedHat based distros (Fedora, Quebes, etc) to my understanding AppArmor is not supported.

You can then enable AppArmor by adding

apparmor=1 security=apparmor

to your bootloader parameters.


If your going the SELinux route you can follow the guides below. I would recommend going this route.

Arch -
Debian -
Fedora -
Gentoo -
Mint -
RedHat -
Ubuntu -

Next we are going to add the other Bootloader parameters starting with the


This with disable slab merging. For those curious a slab is a set of one or more contiguous pages of memory set aside by the slab allocator for an individual cache. If multiple different subsystems wanted to allocate separate 128-byte objects without any special properties, they wouldn't each get separate slab types with separate slabinfo entries, instead would be all merged into one slab type and thus one slabinfo entry. This can be exploited by an attacker and thus should be disabled.

Next add


This will enable sanity checks (F) and redzoning (Z). Sanity checks make sure that the memory has been overwritten correctly. Redzoning adds extra areas around slabs that detect when a slab is overwritten past its real size, which can help detect overflows. If you are interested in other parameters that can be used you can read the linux kernel docs found here -

Next add

init_on_alloc=1 init_on_free=1

This will zero out memory during allocation and free time to prevent leaking any secrets in memory.

Next add this if you use ECC Ram (Xeon, EPYC, Power9, etc)


This will cause the kernel to panic on any uncorrectable errors in memory which could be exploited.

Next add


This enables Kernel Page Table Isolation which mitigates Meltdown and prevents some KASLR bypasses. For those unfamiliar with the Meltdown exploit you can read more about it here -

Next add


This will enable all mitigations for the MDS vulnerability and disable SMT. Disabling hyperthreading may have a significant performance gain as you will lose half of your threads. If you do not wish to disable hyperthreading just remove the ,nosmt part of the line. By not disabling hyperthreading you may be at risk of getting a Spectre attack which you can read about here -

Next add


This forces the kernel to only load modules signed with a valid key which increases security as it makes it harder to load malicious kernel modules. This prevents all out-of-tree kernel modules from being loaded. Some modules such as virtualbox wireguard and nvidia drivers may not load and will require a dkms module as a workaround. You can learn more about DKMS Modules here -

Next add


This causes the kernel to panic on oopses. This will prevent the kernel from continuing to run any flawed processes which can be exploited. Kernel exploits sometimes also cause an oops in which this will also help prevent. If your system crashes when using this it could be due to a buggy driver so you may need to remove that driver or this parameter.

We can install the microcode for the CPU which often provide bug fixes. They are found in ucode packages and can be installed on your distro by installing either the intel-ucode or amd-ucode packages. You can install both if you really wanted to.

Next we want to one of the following lines to the end of our Bootloader configuration options.



This will enable IOMMU to help prevent DMA attacks.

Next we can add


This will enable kernel lockdown which will lock down in the many ways userspace can escalate to kernel mode.

After you have applied these parameters we can move on, if you are using GRUB just run the command below to reconfigure GRUB.

sudo grub-mkconfig -o /boot/grub/grub.cfg

Mandatory Access Control (MAC)

The MAC system gives tighter control over what a program has access to. This means we can prevent our browser from having access to our entire home directory or another application that may only need access to 1 specific folder. This will prevent any exploits from attacking outside of that specific directory the application is aloud to access.

If you selected to use AppArmor over SELinux as your MAC you can create create profiles by running

aa-genprof /usr/bin/(program)

and of course replace the (program) with a name like firefox for example. We can then start using the program as normal and AppArmor will automatically detect what files it needs to have access to and will add them to the profile. You can then check the profile manually to make sure everything is correct as it probably won't cover everything the application will do.

If you want to take it even further. You can setup a system-wide AppArmor policy by using an initramfs hook to confine systemd. You can find out more about that here -

If you chose the SELinux route their's 2 ways of setting it up the first is targeted policy which is the most common use case and Multi-Level-Security (MLS). The configuration should be located at /etc/selinux/config. You can use one of the following documentation to set SELinux up how you would like.

Targeted -


A Sandbox allows us to run programs in an isolated environment that has no, or limited access to the rest of our system.

Bubblewrap is a good choice to use on linux. Those coming from Windows may be familiar with programs such as Sandboxie this is a similar concept.

I would advise switching to Wayland from Xorg if you can as Xorg does have some security flaws however most Window Managers don't support wayland and only a few Desktop Environments offer support for it. You may also notice more bugs with things like games when running Wayland. Both GNOME and KDE offer Wayland support so if you run one of these Desktops you should try switching. If your more into window managers you can check out Sway or WayfireWM.

For those of us stuck with Xorg for the time being note that Xorg windows can have access to another window. This can exploited by screenshot programs or keyloggers and can even go as deep as recording the root password. We can somewhat combat this by running either Xpra (Remote desktop access) or Xephyr which is a nested X server which is what the majority of us will be using. We can install Xephyr on our system with one of the follow commands.

Arch Based - sudo pacman -S xorg-server-xephyr
Debian Based - sudo apt-get install xserver-xephyr
Gentoo Based - emerge -av x11-base/xorg-server
RedHat Based - yum install xorg-x11-server-xephyr

You can learn more about running Xephyr on your system here -

Root Tweaks

First we are going to run

sudo nano /etc/securetty

and remove everything in the file that doesn't have a # in front of the line this will prevent login access to root in other TTYs.

Next we can run

sudo nano /etc/pam.d/su


sudo nano /etc/pam.d/su-l

and add

auth required use_uid

or remove the # in front of the line if it already exists and then save both files.

Next we can run

sudo nano /etc/ssh/sshd_config

and under the Authentication: area you should see the line

PermitRootLogin no

with a # in front of it just remove the # and save the file. If it doesn't exist you can add the line there and save the file.

Next we can run

sudo nano /etc/pam.d/passwd

and comment out all the lines which means make sure there is a # in front of each line. Then at the bottom add this line

password required sha512 shadow nullok rounds=65536

This will increase the number of hashing rounds that shadow will use. It will make an attacker have to compute a lot more hashes to be able to crack your password. Shadow uses 5000 rounds rounds and can be increased as much as you would like however your logins will be slower the more rounds you add. If you would like to add more rounds you can change the 65536 to a number you prefer. You will need to rehash your passwords after applying this setting. You can run


to change your root passwd and you can run

passwd user

replacing user with your username to change the users password.

Some distributions start Xorg with Root access, with Xorg being such a large amount of code there can likely be exploits that can be used to gain root access. We can mitigate this issue by forcing Xorg to be run by the user by running

sudo nano /etc/X11/Xwrapper.config

and then adding the line

needs_root_rights = no

we can check what's running as root and make sure Xorg isn't there by running

sudo ps -U root -u root u

If you would like to lock out the root login access completely you can run

passwd -l root

Extra Tweaks

We can start the extras by running

sudo nano /etc/profile

and then in the first couple lines you should see the umask line. By default it is set 022 which is not very secure. This allows every user read access across the entire system for newly created files. We want to change line to 0077 which will make it so the files can only be read by the owner. If you would like to understand what the numbers mean you can read this post here -

USBs can be dangerous it should go without saying if you find one you shouldn't plug it into your system. If you have never seen a USBKill you can check there page here - you can see a video off some tests with it here - this is just 1 example. Another deadly example can be seen in this thread - where an sh script can be run as soon as the device is plugged in gaining direct access of the system.

You can install USBGuard and set up a configuration file to help with this but for something like a USBKill it will send power to the USB once its plugged in you would have to disable the ports in your BIOS to prevent something like that. Besides disabling in the BIOS as not every System will have that option, you can also add-on the word nousb at the end of the boot parameters covered earlier to prevent USBs from being read this won't block power to the device though so a USBKill attack is still possible. You can read more about USBGuard here -

If your running the linux-hardened kernel you can also add this sysctl configuration setting by running

sudo nano /etc/sysctl.d/deny_new_usb

and add


Direct Memory Attacks (DMA)

Next we can try to combat Direct Memory Attacks (DMA). This requires disabling Firewire which is an old bus system made by Apple that isn't really used today if you have a specific need for one of these ports such as an old iPod or something then be sure to not disable this.

Next thing that will be disable in this config is Thunderbolt, due note not all USB Type-C connections are Thunderbolt. Thunderbolt can be used for many things such as eGPU, Docks, Displays, etc. Some laptops that only have USB-C ports like the Dell XPS or a Macbook rely on Thunderbolt for everything you plan to really do with it like using a display or a dock so it's best to not disable this unless you know your not using these features.

To set these changes we can run

sudo nano /etc/modprobe.d/blacklist-dma.conf

and add

install firewire-core /bin/true
install thunderbolt /bin/true

Of course just remove the line for Thunderbolt or Firewire if you need them.

Core Dumps

Next thing we want to take care of is our Core Dumps. We are going to start with our sysctl by running

sudo nano /etc/sysctl.d/coredump.conf

and add


Next we will disable our systemd coredumps if your running a different init system like runit then you can skip this.

sudo nano /etc/systemd/coredump.conf.d/custom.conf

if the directory doesn't exist it will show a message at the bottom of the nano editor and won't let you save you will need to exit and run this command first.

sudo mkdir /etc/systemd/coredump.conf.d/

Then you can create the file and add this


Then we can disable ulimit dumps. ulimit “ulimit” reports the resource limit of the current user.

We can disable this dump by running

sudo nano /etc/security/limits.conf

in this file we can hold the down arrow to move to the bottom of the file above the line that says #End of file we will add

* hard core 0


Next we can run

sudo timedatectl set-ntp 0

and then run

sudo systemctl disable systemd-timesyncd.service

This will disable NTP (Network Time Protocol). If your time becomes messed up makes sure its correct in the BIOS and you can use timedatectl to manually set your time. By disabling this we resist tracking as the time set on the computer is not an active telling of our location since its manually set. NTP also allows for the possibility of having a replay attacks which you can read more about here -

Editing files as root (vi and nano)

It is unrecommended to run ordinary text editors as root because many text editors can do more than edit text files and this can be exploited. You can try this by opening vi as root by running

sudo vi

If you enter enter ":sh". You will now have a root shell with access to your entire system which an attacker can easily exploit.

we can use sudoedit to combat this. sudoedit copies the file to a temporary location, then opens the text editor as an ordinary user. Then it will edit the temporary file and overwrite the original file as the root user. This way, the actual editor doesn't run as root. To use sudoedit run

sudoedit /path/to/file

By default it will use vi but the default editor can be changed by setting the EDITOR or SUDO_EDITOR environment variable. If you use nano you can run

EDITOR=nano sudoedit /path/to/file

If you use nano we can set that to be the default when sudoedit is run by setting an environment variable. First run

sudo nano /etc/environment

scroll down to the bottom and edit or add the lines

EDITOR=nano sudoedit /path/to/file

make sure there's no # in front of it either.


Network Protocols

First thing we are going to want to do for this section is create

sudo nano /etc/modprobe.d/uncommon-network-protocols.conf

and inside this file we want to put

install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true
install n-hdlc /bin/true
install ax25 /bin/true
install netrom /bin/true
install x25 /bin/true
install rose /bin/true
install decnet /bin/true
install econet /bin/true
install af_802154 /bin/true
install ipx /bin/true
install appletalk /bin/true
install psnap /bin/true
install p8023 /bin/true
install llc /bin/true
install p8022 /bin/true

You may think since it says true that we are loading all these but we are not. "install" basically tells modprobe to run a command instead of loading the module. /bin/true is a command that returns 0 which will do nothing. When put together it tells the kernel to run /bin/true instead of loading the module, which will prevent the module from being loaded.


Lastly we can Blacklist uncommon filesystems. We can run

sudo nano /etc/modprobe.d/uncommon-filesystems.conf

and inside put

install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
install hfs /bin/true
install hfsplus /bin/true
install squashfs /bin/true
install udf /bin/true

Now by all means if you need some of these like HFS for reading macOS drives then remove that line.


Please make sure you actually have all these partitions before setting these If you have only some of them then only set some of them.

To open your fstab config you can run

sudo nano /etc/fstab

Your going to want to find each of your drives mount and in the options line it may not say defaults but your just going to want to add the following after what you have

UUID=xxxx     /          ext4    defaults                      0 1
UUID=xxxx     /tmp       ext4    defaults,nosuid,noexec,nodev  0 1
UUID=xxxx     /home      ext4    defaults,nosuid,nodev         0 1
UUID=xxxx     /var       ext4    defaults,nosuid               0 1
UUID=xxxx     /boot      ext4    defaults,nosuid,noexec,nodev  0 1
UUID=xxxx     /var/tmp   ext4    defaults,bind,nosuid,noexec,nodev 0 1

make sure to replace ext4 with the Filesystem your using for example xfs. The 2 numbers at the end mean Dumping and Fscking so 0 dumping is what we want and the second number as 1 to check the partitions.

nosuid - Do not allow setuid or setgid bits. noexec - Do not allow execution of any binaries on the filesystem. nodev - Do not interpret devices on the file system.

Password Locking Bootloader

We are going to cover Password Locking any changes to the bootloader. You can set this up to prevent editing menu entries and the command line meaning an attacker won't be able to change the bootloader options we set earlier if they cracked through the encryption they will then require this password to do that so this password should be different than your Primary Partition encrypted password if you have one.


We will need 2 terminals open to set this password up. In the first terminal run the command


It will then prompt you to enter the password you would like to use. after typing in your password 2x it will print out something like PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.xxxxxxx we need the grub.pbkdf2.sha512.10000. part and all the numbers and letters after it. Keep this terminal open and in the second terminal run

sudo nano /etc/grub.d/40_custom

and at the bottom of the file add

set superusers="root"
password_pbkdf2 root xxxxxxx

where xxxxxxx is the part of the password you got from the last terminal. If your terminal doesn't let you copy and paste with Control + C and Control + V you can try copying with Control + Shift + C and Pasting with Control + Shift + V or look at the documentation for your terminal.

Next we can create another optional setting if you just want to password lock the boot parameters from being edited and access to the GRUB Console which is basically all we want to do, however you can have it password protect it all like executing a menu entry etc. If you want it be setup where its protecting executing a menu and what not just skip this part. We are going to run

sudo nano /boot/grub/grub.cfg

scroll down a little bit until you see the line ### BEGIN /etc/grub.d/10_linux ### you can also press Control + W and type menuentry as 1 word then enter and Control + W and enter over and over until you reach this spot. Once here you just want to add --unrestricted after your entries name so as an example

menuentry 'Arch Linux' --unrestricted

leave everything after it you just want to add that one option to the first entry.

Lastly we can rebuild our Bootloader configuration by running

sudo grub-mkconfig -o /boot/grub/grub.cfg


We need to start by running

sudo nano /boot/syslinux/syslinux.cfg

and add the line


replace (password) with the password you want to use. If you want to also set a menu password then inside the same file add

MENU PASSWD (password)

Again replace (password) with the password you want to use. Another thing to note is that the passwords can either be plaintext or hashed with MD5, SHA-1, SHA-2-256 or SHA-2-512. If you would like to use one of these hashing algorithms check out this page -


For Systemd-boot we need to run

sudo nano /boot/loader/loader.conf

and add the line

editor no

This will disable all further editing to the Bootloader parameters we set earlier. systemd-boot does not officially support password protecting the kernel parameters however you can use this community tool to add a password if you would like -


For those unfamiliar lynis is an enterprise application for macOS, Linux and BSD based systems. You can read more about it here -

With all of these tweaks so far this should bring you over 65 score and on some distros into the high 70s. Keep in mind this is before any Network settings have been set. I am working on coming out with a networking guide next and will share it here.

Most likely you will have systemd errors if your running on a distro with systemd you can check these issues by running

/usr/bin/systemd-analyze security

try to disable as many of these you dont need. If your not running a server you should remove things like SSH completely unless you have a very specific use case where you need to remote into your system.

If you would further like to increase your lynis score make sure you can install ClamAV, Aide (note there's a special SELinux version if you opted to go that route), RKHunter and OpenVAS and make sure you don't just install these... make sure you enable them in your init system.

ClamAV -
RKHunter -
OpenVAS -

Best Practices

Set your hostname to "host" by running

echo host >> /etc/hostname

Set your username to "user" if you have multiple users you can name them "user1" and "user2"

sudo usermod -l user <old-name>

if you are going with multiple users change the word user to the username you want. Then you can the home directory name by running

sudo usermod -d /home/user -m user

-d or --home flag will tell usermod where to set the new home directory. -m flag will copy the contents of the old home directory into the new one.

If you are going to use a password manager I would recommend KeePassXC as its an offline storage of your passwords. Do not upload your .kdbx file to Google Drive or something just because it's encrypted. If you want a backup of the file store it on a USB or something.

Remove software your not using.

If your running Gentoo or Void Linux you may want to consider switching to musl from glibc as the code base is smaller and many software especially closed source ones are linked with glibc. To run these software on a musl system you will need to create and isolated mounting point on the system if there are any viruses spread this way this may help you combat them.

As Richard Stallman once said "A smartphone is a computer - it's not built using a computer - the job it does is the job of being a computer. So, everything we say about computers, that the software you run should be free - you should insist on that - applies to smart phones just the same. And likewise to those tablets." I would recommend picking up a Google Pixel and looking at the project GrapheneOS which you can find a link to here - If you would like to know why a Google Pixel you can read this article here -

If your looking for a laptop with Coreboot support and hardware switches to disable some functions of the device you can check out the Purism Laptop - and the Framework laptop (at the time of writing doesn't have Coreboot but is planned) -

if you don't have one of these devices you can disable your Microphone and webcam through software however hardware switches cutting off the power to the devices is far more secure as it can't be tampered with. None the less to disable your webcam run

sudo nano /etc/modprobe.d/blacklist-webcam.conf

and add

install uvcvideo /bin/true

For the microphone sometimes it can be tied to the speakers so just keep in mind that by disabling it you may lose your speakers output as well. It may be a better idea to try to unplug the ribbon cable connecting that module and seeing if the system will still POST fine. Again if you really wanted to you can run

sudo ls /proc/asound/modules

it should give back a name which you can then run

sudo nano /etc/modprobe.d/blacklist-mic.conf

and put

install (module-name) /bin/true

just replace the (module-name) with the name it gave you. You can also check you BIOS to see if you can disable it in there to.

You should lock your BIOS with a separate password this will prevent people from being able to boot off a USB Drive to bypass bootloader protections on your device and be able to just focus on your encrypted partitions. Of course this can be bypassed by just removing the storage drive from the system but it's still an extra step for any in person attacker especially if they are trying to leave everything the way it was so you didn't know the system has been touched.

You can also check out the company Yubico to pick up a YubiKey here - This will allow you to not only have the password for user/root but also require the system to have the yubikey plugged into the device to be able to login. They even offer some Keys with fingerprint scanners so they would need the YubiKey and your fingerprint. You can also pick up multiple YubiKeys or use the same key to lock access to accounts in some applications such as KeePassXC there is a good thread about this here if you are interested in reading the pros and cons of something like this -

If you need to use a Virtual Machine please use virt-manager to setup a KVM or QEMU based virtual machine, Gnome Boxes is another good choice. Virtual box has many issues which you can read about in this thread from whonix -


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment