2.4 Main Features and Design Policies
Key Takeaways
- A default Kali installation ships with more than 600 preinstalled security tools, organized into categories and installable in bulk through metapackages
- Kali follows the Filesystem Hierarchy Standard (FHS), so files live where Debian users expect them — a deliberate fix for BackTrack's ad hoc layout
- Kali's custom kernel is patched for wireless packet injection, enabling tools like Aircrack-ng that stock kernels cannot fully support
- Kali images are built with Debian's live-build framework, and Kali supports a wide range of ARM devices such as the Raspberry Pi
- Kali's repositories are GPG-signed, network services are disabled by default, and since 2020.1 the default account is the non-root user "kali"
2.4 Main Features and Design Policies
The Kali Linux Revealed book closes its introduction with a list of features and policies that distinguish Kali from both its BackTrack ancestor and from generic Linux distributions. The KLCP exam draws heavily on this list — expect direct questions on the kernel, the build system, signing, and the service and user policies.
The Headline Features
- 600+ packaged tools. Kali packages more than six hundred penetration-testing and security tools, of which a default installation ships the
kali-linux-defaultsubset, curated into categories (information gathering, wireless attacks, forensics, and so on) that appear in the application menu. Bulk installation happens through metapackages such askali-linux-defaultandkali-tools-top10. - FHS compliance. Kali adheres to the Filesystem Hierarchy Standard, so binaries live in
/usr/binand/usr/sbin, configuration in/etc, logs in/var/log, and so on. This was a deliberate correction of BackTrack's habit of scattering files in nonstandard locations, and it means documentation written for Debian applies cleanly to Kali. - Custom injection-patched kernel. Kali maintains its own kernel builds with patches for wireless packet injection, which compatible adapters need for Aircrack-ng-style attacks. This is one of the clearest examples of Kali adding capability that upstream Debian deliberately does not ship.
- Built from public build scripts. Kali's live images are generated by live-build, Debian's image-building framework; the installer images are built with
debian-cd/simple-cdd, and ARM and cloud images have their own build-script repositories. All of them are driven from scripts in Kali's public git repositories. The practical payoff is reproducibility and easy customization: you can clone the build scripts, change the package list, and produce your own ISO. - A live system. The primary Kali ISO is a full live system: it boots a complete, working Kali desktop straight off the medium without touching the host's disks, and the same image can launch the installer. Forensics mode is a variant of that live boot.
- A trustable operating system. Kali's trust story is more than "the repo is signed": the distribution is developed by a small, known team, every package is signed by its individual developer, and packages are built by trusted build daemons from signed source packages — so you can reason about who touched what.
- Wide ARM support. Kali publishes images for a broad set of ARM devices — Raspberry Pi, various Chromebooks, ODROID, and more — plus the NetHunter platform for Android phones, enabling portable and drop-box assessments.
Security Policies
| Policy | What it means | Why it matters on the exam |
|---|---|---|
| Signed repositories | All packages are distributed over GPG-signed repos; apt verifies signatures via the kali-archive-keyring package | A missing/expired key produces signature warnings on apt update |
| Network services disabled by default | SSH, Apache, PostgreSQL, and similar daemons do not start at boot | A hacking platform must not be hackable out of the box; you enable services explicitly, e.g. sudo systemctl enable --now ssh |
| Non-root default user | Since 2020.1, the default account is the standard user kali (password kali on live images); privilege goes through sudo | The old root/toor model is retired; tools needing raw sockets are handled via sudo or file capabilities |
| A curated collection of applications | Kali deliberately does not package every penetration-testing tool in existence. It ships only the best freely-licensed ones, judged on four criteria: usefulness in a penetration-testing context, unique functionality, licence, and resource requirements | This is the book's second named policy, alongside "network services disabled by default" — those two are the only items Kali Linux Revealed actually labels policies. Signed repositories is a feature ("a trustable operating system"), and the non-root default is a later change; a "which of these is a Kali policy" question keys on curation and disabled services |
The signed-repository policy pairs with Debian's apt machinery: each Release file is signed with Kali's archive key, and any mirror tampering produces hard warnings rather than silent compromise. The disabled-services policy follows the same "secure by default" logic — Kali is a hostile-environment operating system, so the attack surface at first boot is minimized, and persistence of services across reboots is a deliberate administrator choice (Kali even hooks update-rc.d so newly installed services stay off unless you enable them).
The User Policy: From Single Root User to Non-Root Default
The evolution of Kali's user model is a favorite exam topic because it combines history with policy. BackTrack and early Kali ran everything as a single root user — justified at the time because many security tools require raw socket access and other privileges, and inconvenient because a single mistake (or a compromised browser) had unlimited power. With Kali 2020.1, OffSec reversed course: the default account became the non-root user kali, live images use kali/kali credentials, and administrative tasks run through sudo. Tools that genuinely need elevated raw access are invoked with sudo, and some are granted specific file capabilities instead of full root. Root login still exists for those who want it, but it is no longer the default or the recommendation.
Multilingual and Accessibility Support
Kali is translated into numerous languages, and the installer lets you select language and locale up front; the documentation and much of the tool metadata follow. Combined with support for multiple desktop environments at image-build time — Xfce is the default, with GNOME and KDE Plasma also offered — this reflects a policy of making the platform usable for a global professional audience rather than an English-only niche.
Customization as a First-Class Feature
Because images are produced by live-build from public scripts, building a custom Kali ISO is an officially supported workflow, not a hack. The standard procedure:
- Install the prerequisites on a Kali machine:
sudo apt install -y git live-build cdebootstrap curlfor Live ISOs, orsudo apt install -y git simple-cdd debian-cd curlfor Installer ISOs. - Clone the build scripts:
git clone https://gitlab.com/kalilinux/build-scripts/kali-livefor Live ISOs,.../kali-installerfor Installer ISOs (the oldlive-build-configURL now redirects tokali-live), or.../kali-armfor ARM. - Edit the configuration — package lists (add or remove metapackages), desktop environment, preseeded settings.
- Run the build, e.g.
./build.sh --distribution kali-rolling --verbose, and collect the ISO from the output directory.
Teams use this to bake in VPN configs, custom wordlists, or reporting templates so every engagement machine is identical on first boot.
Exam Trap Checklist
- The default desktop is Xfce; GNOME and KDE are alternatives, not defaults.
- The custom kernel's signature patch set is wireless injection — say "performance tuning" and you are wrong.
- Images come from live-build, not remastersys or manual assembly.
- Repositories are GPG-signed; a key error on
apt updatepoints atkali-archive-keyring, not at a broken mirror. - Services like SSH are disabled by default; enabling one is
systemctl enable --now <service>. - Default credentials are
kali/kalion live images, with a non-root default user since 2020.1.
What is the primary reason Kali maintains its own custom-patched kernel instead of shipping Debian's stock kernel?
On a fresh Kali installation, you run ss -tlnp and notice no SSH, Apache, or database listeners. What explains this?