A practical guide to AppArmor and SELinux on elementary OS
Security on elementary OS is built from several layers rather than one master switch. Traditional Unix ownership and permissions protect files, while the Linux kernel, service isolation, application packaging and network controls add further boundaries. AppArmor and SELinux belong to a more specialised layer called mandatory access control, or MAC.
For most desktop users in Australia, AppArmor is the relevant technology because elementary OS inherits much of its security approach from Ubuntu. SELinux is important to understand, particularly if you use Linux at work or manage servers, but it is not normally the default policy framework on an elementary OS installation. Knowing that difference helps you avoid installing a complex security system without a clear reason.
| Security layer | What it controls | Typical elementary OS relevance | Useful check |
|---|---|---|---|
| Unix permissions | Users, groups and file read/write/execute access | Everyday files and home directories | ls -l |
| AppArmor | What a named application may access | Usually available and aligned with Ubuntu | sudo aa-status |
| SELinux | Label-based rules for users, files, processes and services | Possible, but not normally the desktop default | getenforce |
| Flatpak sandboxing | Application permissions and portals | Common for graphical applications | Flatpak settings |
| Firewall | Network connections to and from the computer | Useful on public or shared networks | sudo ufw status |
How access control fits together
Linux starts with discretionary access control, commonly abbreviated as DAC. A file has an owner, a group and permission bits for reading, writing and executing. A standard user account cannot usually alter system files under /etc, /usr or /var, while administrative actions require authentication through sudo.
DAC is useful, but it trusts an application after it has been launched by your account. If a vulnerable program can read your home directory, its access may include documents, browser profiles, SSH keys and saved configuration files. AppArmor and SELinux add rules that restrict what a process may do, even when that process is running as a user who normally has access.
This is especially relevant when a laptop contains tax records, scanned identity documents or files used for myGov and banking. A compromised browser extension or media application should not automatically receive unrestricted access to every personal folder. MAC policies aim to reduce that damage by narrowing an application's permitted behaviour.
The controls are not a replacement for updates, strong passwords or sensible backups. They also do not make an unsafe download trustworthy. A malicious application can still trick a user into granting access, exploit an unpatched component or misuse a permitted function. Think of AppArmor and SELinux as containment tools within a broader security model.
AppArmor on an elementary OS desktop
AppArmor applies profiles to programs. A profile can allow a web server to read particular website files, permit a desktop utility to use selected libraries and deny access to sensitive paths. Rules can also govern capabilities, network activity and operations such as changing system settings.
AppArmor commonly operates in enforcing mode, where violations are blocked, or complain mode, where violations are recorded without being blocked. A profile may be attached to a program by its executable path, so the same application running under different circumstances can receive a defined policy. The exact profiles installed depend on the Ubuntu base, packages and elementary OS release.
You can inspect the current state with:
sudo aa-status
If the command is unavailable, the relevant administration tools may not be installed. Installing tools simply to inspect the system is generally low risk, but creating or changing profiles requires care. Avoid copying a profile from an unrelated Ubuntu version and assuming it matches your desktop, because application paths and permissions can differ.
A useful distinction is that AppArmor generally focuses on “which program is this?” while SELinux focuses heavily on “what security label does this process or object have?” AppArmor’s path-oriented model is often easier for a desktop user to understand and maintain.
Reading AppArmor alerts without panic
A denial in a log does not always mean that malware is present. It may indicate a legitimate application attempting an operation that its profile does not yet permit. For example, a document viewer might try to access a thumbnail cache, or a helper process could request a file location that was not anticipated by its policy.
System logs can be searched with journalctl, although the output can be dense:
sudo journalctl -k | grep -i apparmor
On some systems, AppArmor utilities provide tools such as aa-logprof to review logged denials and suggest policy changes. Read each suggested rule carefully. Granting broad access to a home directory just to silence an alert can remove much of the protection the profile was meant to provide.
Before changing a rule, identify the application, the file or capability involved and the action that was denied. Check whether the event happened when you deliberately opened a document or enabled a feature. An unexpected denial at a time when the program was closed deserves more investigation than a denial that matches a known action.
Do not delete logs or disable AppArmor merely because an application behaves differently. First update the system and the application, check its documentation and look for a package-specific profile. If a program is unreliable under confinement, using a better-maintained package is usually safer than weakening global policy.
SELinux basics and its different model
SELinux also provides mandatory access control, but it uses security labels and a policy language that can describe relationships among users, processes, files, ports and services. A file might be labelled for web content, while a process running a web service receives a domain that limits what it can do with that content.
Its common operating modes are enforcing, permissive and disabled. Enforcing blocks actions that violate policy. Permissive records violations without blocking them, which can assist with testing. Disabled turns the framework off, and switching between disabled and enabled states can require relabelling files or rebuilding policy data.
The main status command is:
getenforce
A broader view is available with:
sestatus
SELinux is strongly associated with distributions such as Fedora, Red Hat Enterprise Linux and their derivatives. Ubuntu and elementary OS traditionally use AppArmor instead. It may be possible to install SELinux packages on an Ubuntu-based desktop, but doing so can affect boot behaviour, services, package configuration and troubleshooting procedures.
That makes SELinux a poor “extra security switch” for most elementary OS users. It is valuable knowledge if your employer operates Red Hat servers, if you are studying Linux administration or if a specific deployment requires it. On a daily-use laptop in Melbourne, Canberra or Hobart, a correctly maintained AppArmor setup is usually a more coherent choice than mixing frameworks.
AppArmor, Flatpak and desktop permissions
AppArmor and Flatpak solve related problems at different levels. AppArmor applies to programs and services across the operating system. Flatpak packages graphical applications with sandbox permissions and uses portals to mediate access to files, cameras, microphones and other desktop resources.
A Flatpak application may therefore be restricted by its own sandbox while the host system applies AppArmor to other components. The two systems do not automatically produce a simple combined permission screen. An application can fail because of a Flatpak permission, a portal decision, a traditional Unix permission or an AppArmor rule.
Review installed Flatpak permissions with:
flatpak list
flatpak info --show-permissions application.id
Replace application.id with the identifier shown by flatpak list. Graphical tools can make these permissions easier to review, but command-line output is useful when diagnosing a problem. Be cautious with permissions such as access to the entire home directory, host operating-system files or unrestricted device access.
This matters on shared household networks and public Wi-Fi in places such as Brisbane cafés or Perth libraries. A sandbox cannot protect an application from every network attack, but reducing unnecessary access to local documents limits what a compromised application can collect. Give a photo editor access to a project folder rather than your whole home directory when practical.
Choosing sensible controls for Australian use
Australian users often combine personal and work activity on the same notebook: online banking, private health correspondence, school documents and business records may sit beside ordinary downloads. The Privacy Act 1988 and its Notifiable Data Breaches scheme apply to organisations in relevant circumstances, not as a personal desktop configuration standard, but they explain why businesses treat access control and incident handling seriously.
If you work with customer information under an Australian organisation, ask which security policy applies before changing system controls. The Australian Cyber Security Centre’s guidance and the Essential Eight are useful reference points for organisations, though a desktop MAC profile is only one small part of those practices. Encryption, patch management, account separation, backups and multifactor authentication remain essential.
For a personal machine, begin with the defaults. Keep elementary OS and installed applications updated, use a separate administrator account where appropriate and avoid running downloaded scripts with sudo. A local firewall such as UFW can reduce unsolicited inbound connections, especially when moving between home NBN, university, hotel and workplace networks.
Use full-disk encryption when installing the system if the computer stores sensitive information. Encryption protects data when a laptop is lost or stolen, including during travel between Sydney and regional areas, but it does not protect an unlocked session from a malicious application. Lock the screen, review browser extensions and keep recovery codes somewhere secure.
A safe troubleshooting workflow
When an application fails, establish the simplest explanation first. Check whether the file is readable under ordinary permissions, whether the application is current, whether a Flatpak permission changed and whether the failure is reproducible with a non-sensitive test file. This prevents a normal application bug from being mistaken for an AppArmor or SELinux issue.
For AppArmor, inspect status and recent kernel messages, then identify the profile involved. Do not paste random commands from a forum into a terminal with administrator privileges. Community advice can be helpful, but commands written for Fedora SELinux systems or older Ubuntu releases may be wrong for elementary OS.
Test policy changes narrowly. If an application needs access to a project directory, prefer a rule for that directory over a rule covering /home. If you temporarily place a profile in complain mode for diagnosis, return it to enforcing mode afterwards and record what changed. Keep a backup of custom policy files so a future system upgrade does not leave you unsure about the intended configuration.
For SELinux, use the distribution’s documentation and policy tools rather than editing labels by guesswork. Commands such as ausearch and sealert may be relevant on an SELinux system, but they are not substitutes for understanding the policy. Never disable a security framework permanently just to make one application work without investigating the underlying denial.
Keeping security effective over time
Security policy becomes less useful when nobody can explain it. Review installed applications every few months, remove software you no longer use and check which Flatpak permissions have expanded. If an application is obtained from an unfamiliar repository, consider whether its source and update process are trustworthy before attempting to write a custom AppArmor profile.
Backups should be tested, not merely configured. Keep at least one backup separated from the computer so ransomware or accidental deletion cannot affect every copy. For Australian households, this is relevant to irreplaceable photos, invoices, identity documents and records needed during tax time. Cloud storage can help, but review its privacy settings and retention behaviour.
A practical baseline is straightforward: leave the distribution’s AppArmor arrangement intact, use Flatpak permissions deliberately, apply updates promptly and use encryption with a strong login secret. Learn to read a denial before changing policy, and treat SELinux as a specialised framework for systems that explicitly require it.
The useful takeaway is to prefer a small, understood security boundary over a complicated one: keep AppArmor enforcing where it is supported, limit application permissions to the folders and devices they need, and investigate each exception before allowing it.
