*I WILL NOT BE RESPONSIBLE FOR ANY INFECTION YOU MIGHT CAUSE*
To handle malware safely requires some understanding of operating systems. This is because, after all, it is your OS that you do not want infected. Buuuut, that being said, you can go about it with minimal understanding and a bit of hassle.
This post is specifically about Linux malware, and so if you're on windows, we assume that you are safe (OSX users beware as you are running BSD).
Malware is malicious software. For software to be malicious it must necessarily perform malicious actions. "Malicious" here is whatever you, as a possible administrator, define it as. For any software to perform any actions, it must be executed...
If you are just doing static analysis, you might be tempted to "just avoid executing it". But you might be surprised to know that this might not be sufficient. In all cases it is like handling dangerous viruses in a glass, but not wearing a hazmat suit. You don't need to stumble much to get a new spicy cold. So, better handle it in protective casing.
Protective stuff
There are several types of protection, but in general they fall into three categories:
Containment
You can contain malware in a safe environment within you OS (at least in theory). A very simple kind of containment is aptly called a "jail". The very very simplest of which are chroot jails. If you are interested in this type of simple jailing you can read about it here https://www.howtogeek.com/devops/what-is-chroot-on-linux-and-how-do-you-use-it/
Essentially it changes a processes apparent root to a new subdirectory, making it unable to perform file system changes outside of this subtree.
If you are after a more modern jail, have a look at google's`nsjail` which is a more comprehensive jail used in industry today. If you want a fun challenge, try and escape a jail like this, such an exploit is probably worth a lot of $$$ but does occur from time to time.
Jails often disallow more things than just access to the file system however. To understand why, just think of crypto-mining malware, it does not need FS access to perform malicious activity. The same goes for connecting to a C2 server, or performing DDOS attacks. Because of this, jails will often also disallow specific OS level functionality. For example you might not want your jailed malware to issue the connect system call. For this purpose we can use the built in seccomp feature, this allows for a process to disallow certain system calls from being made.
This method has a big downside in that if you disallow all system calls the malware is unable to do anything at all. If it tries to issue a system call it will be killed by the OS, and so you will not be able to analyze it.
Containers are essentially advanced jails with restricted system calls, and namespace seperation. They provide an easier to manage interface to customising the "jail interior", so your malware can be nice and cosy. Have a look at Docker and it's capabilities if you are interested in lightweight process containment.
In essence, containment is powerful and it's strength lies in the lightweight nature of it. Remember that this is still running on your OS, and therefore uses the same underlying file system driver, memory, and !kernel!. This means that they can be started and stopped quickly, and do not have a big resource footprint.
I have marked the work kernel above, because this is also it's biggest weakness. Remember that the malware is still sharing your machine, and so there better not be a vulnerability in your OS, or your jail. This would mean that malware could easily escape into your host machine.
Containment is not as safe as seperation, and it sort of goes without saying. It's a lot safer keeping your viruses in a seperate building, than in a locked box.
Separation
Some time ago someone got the great idea of making modern processors capable of switching execution state completely. It gets a little advanced but it allows you to run a computer, inside of your computer...
This is what is known as virtualization, and it is done using hypervisors (great sci-fi naming there). Hypervisors come in a few different flavors namely type 1 and type 2. A hypervisor will host a "guest" operating system. The guest operating system can be any operating system you're used to like windows, linux, and macOS.
A type 1 hypervisor is a kind of operating system that only facilitates hosting guests. This means that it does not support downloading and running your favorite video games, or watching meme compilations on youtube, but only has enough functionality to create and run guest operating systems (you can watch memes on these though). Type 1 hypervisors are things like Xen, and VMWare ESXI.
Type 2 hypervisors are programs that you install in your OS, and facilitate creating guests as well. The upshot is that you get to keep your operating system, and so can use it like a normal computer. The downside is that they are not as efficient as type 1. You will probably be using a type 1 hypervisor a lot. They include KVM, VirtualBox, and VMWare Workstation. I recommend VirtualBox because it is free and open source.
A separate operating system means a separate kernel, so the attack surface for the malware is a lot smaller. The malware could attack and take over the kernel, but it would still be inside the guest OS. Thus this is a lot safer than jails and containment, but the downside is that you essentially need the space and memory to run an entirely different OS inside your OS. Their resource consumption is a lot higher.
You might run in to issues with architectures, as not all computers are made equal. Most computers at the time of writing run on the x86 architecture by intel, but a few Macs have switched to a specific ARM extension with the M1 processor. This means that if the malware you are trying to analyze runs on a different architecture than this, not even the hypervisors will help you. Because they still run on your processor with the specific architecture.
Emulation
Emulation is an interesting and complex field. You might have encountered phone emulators, or console emulators (like for gameboy or gamecube), and they do a decent job.
In essence, emulators do not "run" programs in the traditional sense, but emulate them (duh!). They are pieces of software that implement a specific physical architecture. A good emulator is Qemu that supports almost all architectures under the sun.
Because emulators are emulating hardware in software, they tend to be a lot slower. But they are pretty safe when used right. Because they do not execute instructions, but read and emulate their effects, anything about the execution can be changed. For example I could rewrite the qemu emulator to execute the ADD instruction as a SUB instruction instead and watch chaos unfold.
As long as your emulator is not vulnerable, it should be safe to run them. (Don't use qemu user mode as it gives the emulation access to your computer, use qemu-system instead).