{{Header}} {{Title|title= System Identity Camouflage and Virtual Machine Cloaking }} {{#seo: |description=Feature Request: The ability of an operating system (like {{project_name_short}}, Debian, Qubes, or a generic Linux distribution) to hide its true identity or characteristics from local tracking software or applications. |image=System-identity-camoflage231.png }}
* [[System_identity_camouflage|System Identity Camouflage and Virtual Machine Cloaking]] * [[CPUID|CPUID - Security and Privacy Risks]]
[[File:System-identity-camoflage231.png|thumb]] {{intro| Local System Code Execution Anti-Fingerprinting - Feature Requests: * System Identity Camouflage: The ability of an operating system (like {{project_name_short}}, Debian, Qubes, or a generic Linux distribution) to hide its true identity or characteristics from local tracking software or applications. * Virtual Machine Cloaking: Involves virtual machines being able to operate in a way that makes them undetectable as VMs by standard detection methods used by software or malware. }} = Introduction = This is a discussion of various related feature request with detailed reasoning why it has been determined that it is realistically impossible to implement these. = Threat Model = In computing terms, the [https://en.wikipedia.org/wiki/Threat_model threat model] concerns potential threats or structural vulnerabilities that can be exploited by adversaries; in the case of {{project_name_short}} in context of this wiki page means possible identifiers leading to information leaks. Local code execution system fingerprinting threats arise when a machine is compromised, * '''A)''' infected with malware; and/or * '''B)''' running that have software locally installed which includes anti-features such as privacy-intrusive, tracking elements. For the context of this wiki page, in short called, tracking software. It is important that these threats do not occur without locally running tracking software. Remote fingerprinting that does not require local code execution compromise do exist (see {{whonix_wiki |wikipage=Data_Collection_Techniques |text=Data Collection Techniques }}) but these are outside the scope of {{project_name_short}} because it is not an anonymity operating system project. For that, consider Whonix. = Feature Requests = == Linux Identity Camouflage == "Debian Identity Obfuscation", "Generic Linux Facade", "Linux Distribution Masking" A system characteristic that prevents tracking software from determining the specific Debian-based distribution, only revealing a generic Linux presence. A feature that hides the specifics of the Linux distribution from tracking software, presenting a unified, non-specific Linux identity. == Windows Identity Camouflage == "Windows Emulation Secrecy", "Cross-Platform Windows Illusion" This concept refers to the capability of a Linux system to execute Windows applications, making them believe they are functioning on an authentic Windows platform, without the use of Windows binaries. The core idea revolves around operating a Linux-based system while securely running Windows applications in an environment similar to [https://en.wikipedia.org/wiki/Wine_(software) Wine] (a fork of Wine or alternative). The key challenge is to create an illusion for the Windows software, convincing it that it is running on Windows $current_version. This method, deemed "even more impossible to implement". It relies on the notion that replicating Windows functionality accurately without using original Windows binaries is almost impossible. In theory, it would represent a balance between mitigating local code execution fingerprinting and maintaining security by not utilizing Windows binaries. == Qubes Identity Camouflage == A feature that masks Qubes OS's identity from local tracking software, making it indistinguishable from a (non-Qubes) non-virtualized environment. == Anti-Local Fingerprinting == Inability for tracking software to find out screen resolution and other hardware information. This specific feature request might is actually partially more realistic, see [[Security-misc#Reduce_Kernel_Information_Leaks|Reduce Kernel Information Leaks]]. == Anti-VM Bypass == "Anti Anti-VM", "VM Cloaking", "Invisible Virtualization" This concept pertains to the techniques or technologies in virtual machines (VMs) that enable them to remain undetectable to software specifically designed to identify virtualized environments. There are some software projects working on this but nothing easily combinable with Xen (Qubes) or VirtualBox. The primary goal is to develop VMs capable of concealing their virtual nature. Achieving this is considered extremely challenging, potentially requiring significant investments from virtualization software developers and Linux kernel contributors. This subject appears to be a complex and ongoing challenge, resembling a cat-and-mouse game where anti-VM measures typically outpace the defenders (anti-VM bypass techniques). Proprietary software, including anti-cheat systems and serial number checks https://serverfault.com/questions/727347/solidworks-activation-license-mode-is-not-supported-in-this-virtual-environment , along with malware, often seek to detect VMs. Conversely, malware analysts and privacy advocates are interested in developing anti-VM bypass capabilities. Some malware deactivates itself in VMs to evade detection and analysis. Thus, the detectability of a VM could be viewed as a security feature. Employing anti-VM bypass techniques might enhance local code execution fingerprinting protection but could potentially compromise overall system security. = Ecosystem Wide Issue = This issue is [[unspecific]] to Debian, Qubes, Tails, Whonix, {{project_name_short}}, etc. No operating systems currently offer these features. A significant portion of the terminology used here is non-existent in mainstream discourse and was coined specifically for this wiki page. There is also a general lack of awareness about this issue. For someone aiming to make progress in this area, it would be necessary to first elucidate the issue and then draft feature requests to be sent to various projects. Alternatively, they could initiate or financially support the development of projects focusing on this topic or become a founder. While there is substantial research in the field of computer security and anonymity, as highlighted by resources like [https://freehaven.net/anonbib/ anonbib - Selected Papers in Anonymity], it appears that as of the current date, there is no significant research specifically focused on local code execution anti-fingerprinting. = Impossible to Implement Feature Request = The feature request under consideration is assessed as impossible to implement, given the constraints of current technological capabilities, funding, organizational structure, and the extreme complexity involved in realizing the proposed concept. While it might be tempting to assert that "nothing is really impossible," and theoretically this could be true, it is more accurate to describe this as "realistically impossible." Engaging in semantic debates over this term is not productive, and eventually, the qualifier "realistically" can be omitted for clarity, brevity. It's also important to address a potential misconception that this is an issue {{project_name_short}} is expected to resolve, or is capable of resolving, or is responsible for causing. So the mini [[History|history of {{project_name_short}}]]. '''1''' [https://forums.whonix.org/t/the-problem-with-security-guides-and-how-we-can-fix-it/8563 The Problem with Security Guides] '''2.''' Research, documented security issues, contributors joined efforts, a build automation script was written and later downloadable software has been offered for download. '''3.''' Other security improvements are being worked on. {{project_name_short}} aims to improve the security from remote code execution (RCE) and local privilege escalation (LPE) attacks. See also [[What_we_do|Project Activities]]. However, system identity camouflage is a feature request that the {{project_name_short}} is unable to implement. Furthermore, it seems unlikely that any other Linux distribution will attempt to implement this. For example, as per [https://github.com/QubesOS/qubes-issues/issues/8833 this Qubes issue ticket] it seems highly unlikely that Qubes will work on this issue. The interpretation of the Qubes FAQ section, "[https://www.qubes-os.org/faq/#what-about-privacy-in-non-whonix-qubes What about privacy in non-Whonix qubes?]", suggests a preemptive rejection of feature requests related to enhancing privacy within individual virtual machines (VMs), let alone from local code execution based fingerprinting. This stance aligns with the explicitly stated project goals of Qubes, which focus primarily on isolating VMs from one another. In this context, Qubes aims to ensure that malware running in one VM cannot access data in another, such as preventing a compromised browsing VM from reading GPG private keys stored in a vault VM. However, the project does not explicitly aim to restrict the information that locally running malware can gather within a single VM. This approach by Qubes is understandable, considering the immense difficulty and associated costs of implementing such privacy features. It appears that setting realistic project goals has led to the exclusion of such ambitious objectives. The nature of this discussion goes beyond a simple feature request; it is more akin to a request for an entirely new project direction. This is highly unlikely to happening. Except, perhaps "money talks". Now that {{project_name_short}} developed as far as it got, what's happening now some people are requesting to be able to run malicious, locally compromised software and still have no useful information such as what operating system (such as {{project_name_short}}, Whonix, or Qubes) is being used inside that VM. That's a reasonable request, reasonable development goal. Nobody going to argue against "make thing better". But also totally different ball game. Many of underlying components that {{project_name_short}} is based on that to name a few, Debian, a virtualizer, the Linux kernel aren't primarily projects focused on security, privacy, let alone anonymity. These are independent Open Source / Freedom Software projects with thousands of users. These are not part of a company where the CEO where could order them to change things. In case of example for Kicksecure in Qubes, the virtualizer is Xen. And Qubes is a distribution of Xen. The local VM fingerprinting issues are inherited from Debian, Linux, Xen, Qubes. This is not something that realistically ever can be fixed by {{project_name_short}} because that would cost literally millions of USD to fix these issues at the root. And there's no market of that size and/or appartemently nobody figured out a business model for that either. Computers are notoriously insecure, see: [[Dev/About_Computer_(In)Security|about computer insecurity]] You already have better protection by using a VM instead of, let's say, a Windows host where applications can read unique hardware identifiers. See: {{whonix_wiki |wikipage=Protocol-Leak-Protection_and_Fingerprinting-Protection |text=Protocol Leak Protection and Fingerprinting Protection }} The issue of locally running malicious software reading identifiers, for example linking two or more locally compromised Virtual Machines (VMs) to the same pseudonym, is a known issue see: {{whonix_wiki |wikipage=VM_Fingerprinting |text=VM Fingerprinting }} Organizational structure: * [[Linux User Experience versus Commercial Operating Systems]] * [[Dev/Open_Source_Business_Models|Open Source Business Models]] The {{project_name_short}} can document these imperfections and hopefully motivate others to work on them, but that's all. The {{project_name_short}} cannot possibly solve this issue. Maybe the way to frame it... * Kicksecure is a security-focused OS. * Qubes is security-focused VMs. * There is no privacy-focused virtualizer project or fork of Xen or Qubes. The term "realistically impossible" is used to describe the highly improbable implementation of certain features, primarily due to the technical requirement of modifying source files in other entities' projects. This would involve changes in upstream projects like Linux, virtualizers, Debian, and possibly systemd. However, these projects may not prioritize or even consider the specific needs and opinions of an individual, which is both understandable and expected given the thousands of people with diverse requests. The process to implement such changes is not straightforward. It would require not only explaining the issue clearly but also developing patches that are acceptable to these upstream projects. This is a slow and uncertain process, which might encounter significant obstacles if the upstream maintainers do not perceive the issue as important, relevant, or feasible. The scenario where such changes could become feasible might involve substantial financial backing, akin to the support provided by individuals like Mark Shuttleworth when he founded Ubuntu. If a billionaire or millionaire were to invest significantly in forking a project like GNU Hurd or another microkernel, and establish a project goal dedicated to local code execution anti-fingerprinting, or encourage Xen to add anti-local fingerprinting features, it might be possible. However, this is a highly speculative and unlikely scenario, bordering on unrealistic. It is conceivable that an expert like Marek (Qubes OS lead developer) could provide an estimation or at least a rough guesstimate of the work hours and monetary resources required to implement any of the aforementioned features. However, even soliciting such estimates might be unrealistic. Conducting preliminary research and generating an estimate itself requires time and resources. Given the context, where the end result might only be to determine feasibility without any realistic prospects of further action, it is unlikely that such an estimation would be pursued. = Technical Challenges = The implementation of certain features faces technical challenges, particularly in identifying and modifying specific system files and commands. These include: * The presence of /etc/debian_version, which indicates the Debian version. * The file /etc/os-release, providing details about the operating system. * Utilizing the command {{CodeSelect|inline=true|code=dpkg -l {{!}} grep kicksecure}} to list Kicksecure-specific packages. * Utilizing the command {{CodeSelect|inline=true|code=dpkg -l {{!}} grep qubes}} to list Qubes-specific packages. * The availability of the command which qubesdb-read, relevant in Qubes OS. * The marker file /usr/share/qubes/marker-vm, as mentioned in the [https://www.qubes-os.org/faq/#what-is-the-canonical-way-to-detect-qubes-vm Qubes OS FAQ], which helps identify a Qubes VM. * The output of {{CodeSelect|inline=true|code=xrandr}}, particularly the mention of DUMMY, which is commonly seen in Qubes and can be indicative of a virtual environment. * The output of: ** {{CodeSelect|inline=true|code=mount}} ** {{CodeSelect|inline=true|code=lsblk}} ** {{CodeSelect|inline=true|code=sudo fdisk -l}} ** {{CodeSelect|inline=true|code=systemctl list-units}} ** {{CodeSelect|inline=true|code=env}} * can easily reveal many operating systems such as for example Qubes. * {{whonix_wiki |wikipage=Protocol-Leak-Protection_and_Fingerprinting-Protection#Identifiers_Design_Goals |text=/etc/machine-id }} * Benchmarking: An adversary could benchmark the CPU, GPU, HDD, RAM, other hardware (such as the microphone, keyboard, and camera) and/or network connection to create a unique profile. * [[CPUID]] * /proc * /sys * Existence of ~/QubesIncoming folder. * Many others. = Discussion = * [https://forum.qubes-os.org/t/how-to-hide-the-fact-that-im-qubes-os-from-telegram/22934 How to hide the fact that I’m Qubes OS from Telegram] * [https://forums.whonix.org/t/qubes-identifiers/17994 Qubes identifiers] * Qubes feature requests: ** [https://github.com/QubesOS/qubes-issues/issues/1142 Stop telling VMs the exact physical CPU model in the computer] closed as won't fix. ** [https://github.com/QubesOS/qubes-issues/issues/7523 Feature request: add hardware information masking] ** [https://github.com/QubesOS/qubes-issues/issues/4980 Spoofing CPUID Results in the Linux-Stubdom Crashing] ** [https://github.com/QubesOS/qubes-issues/issues/8833 /etc/machine-id should not be inherited from templates] = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]