I'll start by saying that this question's very broad and shows very little original research, and that this answer shouldn't be seen as an encouragement of that type of question. Instead, this answer hopes to provide some extremely basic safety tips for folks just starting out with malware analysis.
Working under the assumption that you're running known, previously-researched malware, how you isolate your environment depends heavily upon what that malware is capable of. Some general rules that apply to most modern malware might be to:
Isolate your VM from the internet. This can be as simple as not setting up interface forwarding to the guest machine, and prevents the malware from communicating with any potential command-and-control nodes that might direct it to act unpredictably.
Use an appropriate hypervisor. There are a few major ones on the market, including VirtualBox, HyperV, QEMU, and macOS's
Hypervisor.framework, to name a few; some of these are actively targeted by malware, and depending on the version, might be vulnerable to the malware breaking out of the guest machine.
Definitely don't install guest additions, or some other platform's analogue. The literal goal of this kind of software is to establish integration between the guest and host, effectively weakening separation between them. I'm not a malware researcher, but I'd be surprised if there wasn't malware that specifically targets this kind of surface.
To address some of your points directly:
How isolated can a virtual machine be made from the host?
At this point, a VM can be pretty thoroughly isolated, but some functions still have to go through the host more-or-less directly, with little hypervisor protection. Right off the bat, most non-KVM virtual machines (like VirtualBox) won't share a kernel with the host OS. This alone serves as a blocker against numerous exploit classes, most notably blocking the ability to run arbitrary syscalls against your host kernel (with the notable asterisk that a broken VM layer implementation can allow for malware to get around this in less obvious ways).
Your VM still has a process space within your host machine's hardware, though -- and while this isn't generally a risk because modern OSes provide decent process space isolation, it can still be used to exploit extremely low-level attacks like a rowhammer, where a process sequentially writes to memory in a specific way until it can read adjacent memory blocks that it doesn't own -- effectively allowing leakage of memory between processes.
Also worth noting that isolation tends to go away somewhat when you want to do essentially any kind of I/O: input and output necessarily mean passthrough, which exposes an attack surface which can be leveraged to perform host actions. This includes HID passthrough like a mouse and keyboard, as well as things like network passthrough -- although this is generally dependent on how well-implemented the I/O passthrough is implemented in your VM.
Should I (or can I?) set up a firewall between the guest and the host?
It depends, but it's generally not a bad idea. Most of the major platforms support hypervisor-level firewalls. These are at most as permissive as the firewall on your host machine, which is in turn at most as permissive as the firewall on your LAN or VLAN. If you want to leverage this instead of cutting off network access entirely by disconnecting the virtual network interfaces, I'd recommend doing research into which ports and hosts your selected malware targets and going from there.
Are guest add-ons a security risk?
Yes. They allow for all kinds of integrations between your host machine and guest machine, and don't always feature open specs where you can see what's being opened up; see above.
What about shared directories?
That depends on how you're doing it, but it's often a bad idea. Many hypervisors do this by creating a virtual drive mounted within the guest machine whose root is in that directory. Depending on the implementation of that mechanism, which can vary slightly between frameworks, you may or may not be safe, depending on what malware you're trying to test.
My concern is that you've performed very little research into this, and that you may end up harming your machine or your data. Before you continue, I'd advise you to look into the different isolation mechanisms on common OSes (KVMs, how they integrate with higher-level virtualization frameworks (virtual-machine), containers (container), and the
chroot mechanism (chroot) to name a few), when each is appropriate, and what they can and can't do. At that point, you'll be able to better judge whether or not you can safely play around with malware in an appropriately-isolated environment.
Finally, you shouldn't engage in trying to work with new or little-known malware (unless you're a seasoned security researcher, but this answer isn't aimed at seasoned security researchers). Malicious actors are extremely creative when it comes to what they exploit and how they exploit it. To get an idea of this, have a look at any recent DEFCON talks that aren't centered around social engineering or gaining physical access through mechanical means.