Computer Security Introduction

Kicksecure ™

Download

On Computer USB Installation Intel / AMD64 ARM64 Raspberry Pi PPC64 Windows (VM) Mac Linux (VM) VirtualBox (VM) Qubes (VM) KVM (VM) Debian morph to Kicksecure More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

MAC Address Documentation Reasonable Security Previous page: MAC Address Index page: Documentation Next page: Reasonable Security Computer Security Introduction

Kicksecure comes with many security features. Kicksecure is Security Hardened by default and also provides extensive Documentation including a System Hardening Checklist. The more you know, the safer you can be.

This page is an introduction to computer security.

Introduction

Before reviewing chapters in the Computer Security section, be sure to also read the Warning page.

Wiki entries in this section purposefully focus on:

• General computing security information.
• Host operating system security advice.
• Preparatory steps before installing Kicksecure using a Type I hypervisor (Kicksecure for Qubes) or a Type II hypervisor like VirtualBox or KVM.

Essentials

"Security is a process, not a product." -- Bruce Schneier, encryption and security expert.

It is important to understand that Kicksecure and all general software cannot guarantee absolute anonymity or security; 'perfect security' is a mirage. The reason is flaws in hardware and software are ever-present, as continual upgrades and patches inevitably introduce further coding or design errors which attackers of varying skill can profit from. As a consequence, the best approach is to try and mitigate risk exposure and provide defense in depth.

With this understanding, a material improvement in security and anonymity requires 'raising the bar' against potential attackers and eavesdroppers:

Security is a process, not a product. It is also about economics. Briefly explained, each attacker has a set of capabilities, privileges, and a certain amount of budget, time and motivation. Given enough of these resources, security of any process will fail; the goal when securing a system is to add layers of security that make attacks too expensive. Nation-state actors have massive budgets, and no single system can be made secure enough against targeted attacks. However, if widely deployed, systems that cannot be compromised with automated attacks, increase the attacker's cost linearly and thus force the attacker to pick targets. Such systems are the only way to make mass surveillance infeasibly expensive.

• The Computer Security Education section
• Post-installation Security Advice
• Warnings

If you have more time available, then it is recommended to read the Documentation widely.

Motivation

If motivation is needed to secure your computer, refer to these articles:

• The Scrap Value of a Hacked PC, Revisited (blog post).
• The Value of a Hacked Email Account (blog post).

If the reader is time-poor, then just review the Hacked PC or Hacked Email figures, or briefly scan the summary tables below.

Hacked PC

US journalist and investigative reporter Brian Krebs notes there are a large number of malicious uses for hacked PCs, including ransomware, bot activity, stolen account credentials, webmail spam and much more.

Value of a Hacked PC

Category	Attacker Activity
Account Credentials	eBay/Paypal fake auctions Online gaming, website FTP, Skype/VoIP credentials Client-side encryption certificates
Bot Activity	Zombies: spam, DDoS extortion, click fraud and CAPTCHA-solving Anonymization proxy
Email Attacks	Webmail spam Stranded abroad advance scams Harvesting email contacts and associated accounts Access to corporate email
Financial Credentials	Bank account and credit card data Stock trading account Mutual fund / 401k account
Hostage Attacks	Fake anti-virus Ransomware and email account ransom Webcam image extortion
Reputation Hijacking	Facebook, Twitter, LinkedIn, Google
Virtual Goods	Online gaming characters, goods/currency OS and PC game license keys
Web Server	Phishing, malware download site Warez/privacy, child pornography server Spam site

Hacked Email Account

Krebs also notes the significant value of a hacked email account. Just one breach of an online email service permits the theft of valuable personal data, account/contact harvesting, re-sale of retail accounts, spam and much more. An email account is a particularly weak link, since once under the attacker's control they can reset the password, along with the passwords of many linked services and accounts.

Value of a Hacked Email Account

Category	Attacker Activity
Employment	Forwarded work documents and work email Fedex, UPS, Pitney Bowes account Salesforce, ADP accounts
Financial	Bank accounts Email account ransom Change of billing Cyberheist lure
Harvesting	Email, chat contacts File hosting accounts Google Docs, MS Drive, Dropbox, Box.com Software license keys
Privacy	Your messages, calendar, photos, Google/Skype chats Call records (+ mobile account) Your location (+ mobile/itunes)
Retail Resale	Facebook, Twitter, Tumbler, Macys, Amazon, Walmart i-Tunes, Skype, Bestbuy, Spotify, Hulu+, Netflix Origin, Steam, Crossfire
Spam	Commercial email Phishing, malware Stranded abroad, email signature and Facebook/Twitter scams

General Advice

Achieving greater security depends on how much time the user is willing to invest in Kicksecure configuration. Security also rests upon the daily practices and procedures that have been adopted by the user, see Documentation.

Backups

It is important to store multiple, encrypted backups of sensitive data.

If the user does not possess at least two copies of the original data, then it should be considered lost. The reason is data on one medium might become inaccessible and beyond repair at any minute. In this case, the computer would not even detect the risk, so data recovery tools would not be of help either.

Best practice recommendations:

• Store the original, encrypted file on a medium like the internal hard drive.
• Create a first encrypted backup: for example, on an external hard drive from manufacturer A.
• Create a second encrypted backup: for example, on an external hard drive from manufacturer B.

For greater security and to protect from incidents like fire or theft, backups in separate physical locations are recommended. Additionally, backups can be stored on remote servers, but the user must be sure it is encrypted properly.

Safer Upgrades

• Kicksecure: If running VM instances are not shutdown, there is a cross-contamination risk for new machines being imported into the virtualizer. For example, this is possible if a powerful adversary has taken control over those VMs currently in use. This action is not required if the user intends to create a new virtual network for the machines being imported.
• Kicksecure-Qubes: Before upgrading Kicksecure Templates, close as many open VMs as possible. Do not run VMs from different domains at the same time as upgrading.

File Storage Location

It is unsafe to store files directly in the root section of the home folder (like /home/user). It is far better to use a sub-folder and store the file there, for example:

• Non-ideal storage location: /home/user/some-document
• Safer storage location: /home/user/my-documents/some-document

The following sub-folders in the home directory should also be avoided:

• ~/tmp
• ~/Download
• ~/Downloads
• ~/download
• ~/downloads
• ~/Desktop

If files are downloaded to the ~/Downloads folder -- the only folder available if the Tor Browser AppArmor profile is enforced -- then move them elsewhere. A folder of your own choosing will keep its contents private from any confined application that is later (hypothetically) compromised.

Other folders that should also be avoided include:

• /media
• /srv
• /net

It is easy to choose folder names which are better than the default naming convention. As soon as a user prepends or appends a random number or string to a folder (such as my-), this makes it unlikely that AppArmor profiles or possibly other mandatory access control frameworks will allow access to these folders by default.

Another reason is that some commands such as sudo rm -rf /var/lib/apt/lists/* (sometimes useful in case of APT issues) are unsafe if a typo is made. If a space is added before the asterisk symbol ("*") by mistake then this would by default delete all files (except hidden files) in the user's current folder (often the home folder). (But not folders in that folder).

Untrusted Input and Attack Surface

• Untrusted input: Untrusted input is any data that an attacker can influence, directly or indirectly. This includes files and device contents from the internet, removable media, and data received over the network.
• Code meets input: If software processes untrusted input, unexpected behavior can occur. In the worst case, a bug can be exploited for unwanted code execution, leading to system compromise.
• Not only "running": Risk is not limited to explicitly "running" something. Many routine actions cause software to parse, interpret, or walk through untrusted structures, sometimes automatically.
• Any relationship adds risk: Wherever code touches untrusted input in any way, there is potential attack surface.

What counts as untrusted input

Untrusted input includes, but is not limited to:

• Internet downloads: Files downloaded from the internet.
• Attachments: Email attachments and chat attachments.
• Archives and images: Archives (for example ZIP, 7z, tar) and disk images.
• Removable media: Removable media (USB drives, SD cards) and external disks.
• Network files: Network provided files (SMB, NFS, WebDAV) and content from untrusted servers.
• Device supplied data: Device supplied data (USB descriptors, storage metadata, filesystem metadata).

Why "just handling a file" matters

Many components interact with a file or device before you explicitly "open" it in an application:

• Operating system parsing: The operating system and kernel may parse device, partition, and filesystem structures.
• File manager helpers: File managers may generate previews (thumbnails), and extract metadata.
• Indexing scans: File Indexing may scan content for search.
• Security scanners: Antivirus or content scanners may parse file formats. See also Malware and Firmware Trojans and The Utility of Antivirus Tools.
• Display and logging: Terminals and logging tools may display untrusted filenames and metadata, including unusual or confusing characters.
• Complex parsing logic: Any of these steps can trigger complex parsing logic.
• Bug density: Complex parsers tend to have more bugs, and some bugs can be exploited.
• Even "simple" utilities: In theory, even small and ubiquitous command line tools such as grep and find could be vulnerable, because they still process attacker-influenced strings, filenames, directory structures, and file contents. However, their attack surface is often smaller than complex format parsers, so public vulnerability reports may be rarer. For example, at the time of writing CVE Details lists no vulnerabilities created in the last 10 years for GNU Grep and GNU Findutils:

  • We don't have any vulnerabilities for this product, created in the last 10 years

• No CVEs ≠ no risk: A lack of reported CVEs can also reflect lower scrutiny, different reporting practices, or bugs that have not been found or disclosed yet.

Common high risk interaction points

• Mounting an untrusted filesystem: Mounting a specially crafted filesystem image can exercise kernel filesystem drivers. This is high impact because it runs in kernel space. Crafted structures can target parsing of superblocks, directory entries, extended attributes, compression layers, and journaling metadata.
• Connecting untrusted devices: Plugging in a crafted device can trigger kernel drivers before any file is accessed. For example, a USB device can present descriptors or behave as multiple device types, which can reach complex driver code paths.
• Opening crafted files: Opening files such as PDFs, images, documents, and media formats uses user space parsers. These parsers are frequently targeted because file formats can be complicated and widely supported.
• Automatic parsing by desktop services: Browsing a folder can trigger thumbnail generation, preview extraction, and indexing. This can happen without user intent, simply because a graphical environment is trying to be helpful.
• Rendering untrusted filenames: Even displaying filenames can be risky in some contexts. Filenames can include unusual characters. Some terminals and tools may interpret control sequences, which can cause misleading output or unsafe copy and paste behavior.

Risk factors that increase the chance of compromise

The likelihood and impact of exploitation depend on several factors:

• Privilege level: Kernel space code and privileged services are higher impact targets than a sandboxed user space application.
• Parser complexity: The more complicated the format and the more features supported, the larger the attack surface tends to be.
• Automatic processing: Any feature that processes content without explicit user action increases exposure, because it can run unexpectedly and repeatedly.
• Exposure history: Code that is widely targeted or historically bug prone may carry higher practical risk.

Defensive strategies

The goal is to reduce how much privileged code touches untrusted input, and to move risky parsing into disposable or isolated environments.

• Prefer isolation for untrusted content: Handle unknown files and devices in an isolated VM (see Multiple Kicksecure) or other disposable environment. Treat that environment as expendable.
• Minimize kernel exposure: Avoid mounting unknown filesystem images on your main system. If mounting is required, do it in an isolated environment and prefer read only access.
• Disable or reduce automatic parsing: Consider disabling (or keep disabled if disabled by default) automount, thumbnail generation, and indexing for untrusted locations. Automatic helpers increase exposure.
• Use restrictive mount options: When mounting untrusted media, use restrictive options such as ro, nosuid, nodev, and noexec where applicable. These options can reduce the impact of some attacks, but they do not prevent exploitation of filesystem parser bugs. Related: Dev/remount-secure
• Treat filenames as untrusted strings: Do not assume filenames are safe to print, log, or pass to commands without proper quoting and escaping. Prefer tools and settings that avoid interpreting control sequences. See also Hidden Text Attacks; Invisible Malicious Unicode Risks; Shell Scripting.
• Keep systems updated: Many real world attacks rely on already fixed vulnerabilities. Apply security updates promptly, especially for kernels, browsers, document viewers, archive tools, and media codecs.

Recommended workflow for unknown files

1 Move the file into an isolated environment.

Handle unknown files inside a disposable VM or other isolated workspace rather than your primary environment.

2 Prevent automatic parsing.

Disable previews, thumbnails, and indexing (or keep disabled if already disabled by default) for the location where the file will be inspected, if possible.

3 Inspect before opening.

Prefer simple inspection methods first, such as checking file type and metadata using minimal tools.

4 Open with the least privilege possible.

Use sandboxed viewers and avoid running content with elevated privileges.

5 If mounting is required, mount read only with restrictive options.

Use ro, nosuid, nodev, and noexec where applicable, and do this inside an isolated environment.

6 Done.

Untrusted content has been handled in an isolated environment with reduced automatic parsing and reduced privilege.

Notes and limitations

• Sandboxing is not perfect: Sandboxing reduces the impact of many exploits, but it is not perfect. Defense in depth is still required. See also: AppArmor. Related: sandbox-app-launcher; vm-app-manager.
• "Safe" is relative: "Safe" actions are relative. The aim is to choose lower risk actions and to perform higher risk actions only in isolation.
• Technical details: See also About Computer (In)Security.

Known Bugs

To learn about known bugs affecting all platforms, see here. Refer to the issue tracker for a list of all open issues affecting Kicksecure.

Greater Security and Next Steps

After reading and applying relevant steps outlined in this section:

• Kicksecure:
  • VirtualBox: download and verify the Kicksecure images before importing them.
  • KVM: Follow the KVM setup instructions to download, verify and import the Kicksecure images.
  • Kicksecure-Qubes: Follow the stable Kicksecure-Qubes instructions.

In all cases, users should follow the Post-installation Security Advice.

For greater security pre- and post-Kicksecure installation, users should read the Documentation pages widely to learn more about potential threats and mitigations. For instance, users might like to consult the Design pages, and consider the recommendations outlined in the Basic Security Guide and Advanced Security Guide sections. Users with limited time can refer to the System Hardening Checklist.

Stay Tuned

It is recommended to read the latest Kicksecure news to stay in touch with ongoing developments, such as notifications about important security vulnerabilities, improved Kicksecure releases, other software updates and additional advice.

Advanced Security Guide

After reading this chapter, it is recommended to refer to the Advanced Security Guide Introduction section for even more security advice.

Footnotes

MAC Address Documentation Reasonable Security Previous page: MAC Address Index page: Documentation Next page: Reasonable Security

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2026 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 14 year success story and maybe DONATE!