Hi there,
I was wondering how to lock/block system settings für "normal" user accounts. Especially the "lock screen" menu.
I would like to force a lock screen after 5 minutens but users can change it via Settings - Privacy - Lockscreen right now.
Is there any way to force a lock screen via my admin/sudo user account for our social work company?
Thanks a lot and best!
Perhaps this site can help you:
With e.g. dconf editor or
dconf watch /
you can find out the path.
/org/gnome/desktop/session/idle-delay
/org/gnome/desktop/screensaver/lock-enabled
I tested it in a Zorin 18.1 Core live session (created the files in the admin account), and it worked for another normal user account.
You need root rights, so elevate to root.
First create the user file at /etc/dconf/profile
Then create the folder /etc/dconf/db/local.d/locks
and into it put two files idle-delay and screensaver.
At /etc/dconf/db/local.d also put two files idle-delay and screensaver.
The content of the files you see on my screenshot.
Save the files and then run in terminal
sudo dconf update
The other user now is not able to disable the lockscreen or to reduce/enlarge the idle time.
They can change the time in the settings app, but it does not take effect and is reset after the settings app is closed.
I hope it is right this way, I'm no administrator and I'm not familar with that topic.
You see, the automatic lockscreen is greyed out now for the user.
The administrator account is also included into that rule here. Perhaps you can exclude the administrator account if you need it.
It's too bad that nobody gave me any feedback... It took me a really long time to find a solution because that was new to me.
The problem kept bothering me because I didn't like that administrators were included to that rules, and since then I've kept looking into what could be done to exclude administrator accounts or special users from the restricted settings.
With the help of AI I got it to work today.
I did the following. The names of the group, profile or files are free.
I created a new group ("restricted_users") which shall have the restricted settings.
Then I added the users to that group which shall have the restricted settings, in my case the user named "tester".
Then I created a profile named "restricted_profile" and created the files for the locked-settings and the locked values.
Then I updated the database with "sudo dconf update".
Now I added at the end of the ~/.profile file of all the users which are in the restricted group the line
export DCONF_PROFILE="restricted_profile"
and set the write permissons of that file to only root or sudo group to avoid that users remove that line.
The administrator account is not restricted now and the administrator can make all settings as he want, but the accounts of the users in the group restricted_users are restricted and the users can not change the settings of the idle-delay and lock-screen turning on after 5 minutes.
Edit: I read that it isn't a good idea to set the permissions of the ~/.profile file to read-only for the users. That can lead to problems. I'll have to find a better solution for that.
Nice tutorial 
Now I've found a good solution for setting up two different dconf profiles (one "user" profile with restricted settings and one "special" profile without) and preventing regular users from changing their profile.
As I mentioned in my first post, I created a user profile and set the restricted settings for it.
Then I created a new group (named "special_users") and added selected users—for example, myself—to that group.
Next, under /etc/dconf/profiles, I created a new profile named "special" in addition to "user" and set there user-db:user (no system-db!).
I set the permissions of that /etc/dconf/profile/special-file for the group special_users to read-only and for others to none (that is important!)
In /etc/environment.d, I created a text file named dconf.conf with the content DCONF_PROFILE="user", which sets the "user" profile system-wide for all users.
The last step was to add the line export DCONF_PROFILE="special" to ~/.profile for all users of the group special_users to override the Profile which is set at /etc/environment.d.
Even if regular users would add this line to their ~/.profile file (if they have enough knowledge to find out the names of the dconf profiles), it won't do any good, since they don't have read access to the profile and therefore can't load the special profile.
It's interesting that GNOME is far more customizable than Zorin Lite with XFCE desktop when it comes to locking settings. In XFCE, there's no way to lock many settings (only for some it seems to be possible), but the documentation how to do this in current xfce is even worse than in gnome.
Unfortunately, I'm not entirely sure if everything is correct this way. There's so little help on this topic online...
Edit: This solution also doesn't seem to be safe from changes made by users. If regular users add export DCONF_PROFILE="" to their ~/.profile, it no longer works as intended. In my test, then one of the settings was still locked, the other not...
I think it’s also better to add the DCONF_PROFILE environment variable to /etc/environment instead of /etc/environment.d, since I’m not sure if I created or named the dconf.conf file correctly.
Hi @Forpli great work friend. As you know I don't use Zorin anymore, otherwise I would have given you feedback. It's great that people like you go the extra mile and share for the benefit of others. This is what community is all about. 
Thank you very much for the compliment! I'm not entirely satisfied with the solution myself, because I haven't yet found a way to prevent experienced users from getting around the restricted profile. I found no documentation how companies make that. Perhaps they use additional software.
I also tested changing the permissions of the /usr/share/applications/gnome-privacy-panel.desktop file to be not displayed in the settings app and to set other default values for the privacy settings, and disable the access to run the terminal and run a command line / Alt+F2 for the normal users...But I think experienced users find a loophole.
I considered creating a polkit rule for the privacy settings so that authentication would also be required for them, but it was too difficult for me to figure out the action ID.
Possibly something else to look at:
" AppArmor is a Linux Security Module (LSM) that implements Mandatory Access Control (MAC) to confine applications, limiting their access to files, network resources, and capabilities regardless of user permissions. It is the default security module on Ubuntu , Debian , and SUSE , and is widely used in enterprise environments to harden servers, databases, and web services.
To effectively lockdown Linux in an enterprise setting, follow this structured approach:
Verify and Enable : Check the status with sudo aa-status and ensure the service is active via sudo systemctl status apparmor . On systems where it is not default, install tools with sudo apt install apparmor apparmor-utils apparmor-profiles and ensure the kernel is booted with security=apparmor .
Adopt a "Complain First" Strategy : Never enable a new profile directly in Enforce mode on production. Use Complain mode (sudo aa-complain /path/to/binary ) to log violations without blocking them, allowing you to identify necessary permissions for the application.
Generate and Refine Profiles : Use sudo aa-genprof /path/to/binary to interactively generate profiles based on application behavior, or manually edit profiles in /etc/apparmor.d/ . Use sudo aa-logprof to review logs from Complain mode and automatically generate rules for allowed actions.
Enforce and Monitor : Once validated, switch to Enforce mode (sudo aa-enforce /path/to/binary ) to actively block unauthorized access. Regularly monitor logs for violations and update profiles as applications evolve.
Target High-Risk Services : Prioritize applying strict profiles to network-facing daemons (e.g., nginx , MySQL , Postfix ) and utilities that process untrusted input, as these offer the highest return on security investment by limiting the blast radius of potential compromises.
By systematically applying these profiles, enterprises can significantly reduce the attack surface, ensuring that even if an application is compromised, the attacker’s ability to move laterally or access sensitive data is severely restricted.
AI-generated answer. Please verify critical facts.
How to integrate AppArmor with Docker containers?
Integrating AppArmor with Docker involves leveraging Docker's built-in support for Linux Security Modules to confine container processes. By default, Docker applies a moderately restrictive profile named docker-default to all containers on AppArmor-enabled hosts, but enterprises often require custom profiles for stricter isolation.
Docker automatically loads and applies the docker-default profile unless explicitly overridden. This profile blocks dangerous operations like mounting filesystems, writing to sensitive /proc or /sys paths, and loading kernel modules, while allowing standard application functionality.
To verify the active profile and status:
sudo aa-status | grep dockerdocker inspect <container_id> --format '{{.AppArmorProfile}}'If the output shows docker-default , the integration is active. If it returns empty or unconfined , AppArmor may be disabled or bypassed.
Docker default AppArmor profile docker-default
View all
For enterprise workloads, the default profile is often too permissive. You can create and apply custom profiles to restrict specific containers based on their least-privilege requirements.
Define a profile in /etc/apparmor.d/ (e.g., docker-webapp ). Use the flags=(attach_disconnected,mediate_deleted) syntax standard for containers.
# Example: /etc/apparmor.d/docker-webapp
#include <tunables/global>
profile docker-webapp flags=(attach_disconnected,mediate_deleted) {
#include <abstractions/base>
# Include specific rules for your app
network inet tcp,
/usr/bin/nginx mr,
/var/www/** r,
deny /etc/shadow r,
}
Load the profile into the kernel:
sudo apparmor_parser -r -W /etc/apparmor.d/docker-webapp
Apply the profile at runtime using the --security-opt flag or in Docker Compose.
Docker CLI:
docker run --security-opt apparmor=docker-webapp -d nginx
Docker Compose:
services:
web:
image: nginx
security_opt:
- apparmor:docker-webapp
how to apply custom AppArmor profile to Docker container
View all
Misconfigured profiles can cause containers to crash or fail silently. Use the following workflow to tune policies without disrupting services:
complain mode. This logs violations without blocking them.sudo aa-complain /etc/apparmor.d/docker-webappcomplain to the profile flags: profile docker-webapp flags=(...,complain) { ... }sudo journalctl -k -f | grep apparmor or sudo tail -f /var/log/syslog | grep apparmoraa-logprof or aa-genprof to interactively update the profile based on logged events, then switch to enforce mode (sudo aa-enforce /etc/apparmor.d/docker-webapp ).troubleshooting AppArmor Docker container permissions
View all
Disabling for Specific Containers : In rare cases where AppArmor conflicts with specific legacy applications, disable it per-container using --security-opt apparmor=unconfined . Avoid this in production unless necessary.
Layered Security : Combine AppArmor with seccomp profiles. While AppArmor controls file and network access, seccomp filters system calls. Using both provides defense-in-depth.
Orchestration Tools : If using Portainer or similar UIs, apply profiles via the "Security & Host" section of the container creation wizard by entering apparmor:docker-webapp in the security options.
What are common AppArmor syntax errors?
Common AppArmor syntax errors typically stem from missing delimiters, incorrect rule ordering, or misunderstandings of how specific operations like ptrace are logged and handled.
The most frequent syntax error is omitting the trailing comma at the end of a rule. AppArmor requires every rule (file, network, capability) to end with a comma. Without it, the parser fails to load the profile.
/etc/myapp/config.json r/etc/myapp/config.json r,AppArmor profile syntax trailing comma error
View all
Administrators often misinterpret DENIED logs related to ptrace , leading to incorrect rules. The kernel may log a ptrace denial as a capability denial (sys_ptrace ) depending on the context (e.g., crossing UID boundaries) or the specific /proc file being accessed.
capability sys_ptrace, when the application actually needs ptrace rules, or vice versa.ptrace rule with peer constraints. For example, netstat -p often requires:deny capability sys_ptrace,
deny ptrace,
Or, if access is needed:
capability sys_ptrace,
ptrace (trace) peer=@{profile_name},
Using deny rules for ptrace is a common strategy to silence logs for tools that scan /proc but do not actually need to trace processes, as deny rules do not generate log entries.
AppArmor ptrace vs capability sys_ptrace denial site:reddit.com
View all
aa-logprof Parsing Failures and Infinite LoopsThe aa-logprof tool can fail or hang due to syntax issues in the logs it parses or bugs in older versions.
aa-logprof (specifically around Ubuntu 14.04/Trusty) contained bugs where parsing signal or specific ptrace log entries would cause the tool to enter an infinite loop or crash with a UnicodeDecodeError . This often happens if the kernel version and user-space tools are mismatched.aa-logprof may fail to read logs if they are in an unexpected format (e.g., reading /var/log/messages instead of audit.log or kern.log ), resulting in "no events found" errors./var/log/audit.log permissions are too restrictive (e.g., not readable by the user running the tool), profile generation will result in empty or incomplete profiles.aa-logprof infinite loop signal ptrace bug
View all
Confusion between file and directory rules often leads to unintended access grants or denials.
/var/log/myapp rw, applies to a file named myapp . To apply to a directory , a trailing slash is required: /var/log/myapp/ rw, .* matches files only in the immediate directory. Using ** is required for recursive matching. A common error is using /etc/myapp/* when /etc/myapp/** is needed to cover subdirectories./usr/bin/myapp mr, (or similar) prevents the application from starting.AppArmor globbing * vs ** directory slash error
View all
Profiles often fail because they lack essential system access rules provided by abstractions.
The Error: Manually writing rules for standard system calls (like accessing /proc , /sys , or shared libraries) instead of including standard abstractions.
The Fix: Always include #include <abstractions/base> at the start of a profile. Depending on the app, nameservice , ssl_certs , or python abstractions may also be required to prevent basic functionality breakage.
How does AppArmor compare to SELinux?
The fundamental distinction between AppArmor and SELinux lies in their security models: AppArmor is application-centric and path-based , while SELinux is system-centric and label-based .
AppArmor attaches profiles directly to executable paths (e.g., /usr/bin/nginx ). It defines what resources that specific program can access. This model is intuitive, as policies mirror the filesystem layout and application behavior, making it easier for administrators to write and audit rules without deep security expertise.
SELinux assigns labels (types, roles, users) to every process and file (inodes). Access is determined by a global policy defining interactions between these labels, regardless of the file path. This Type Enforcement (TE) model offers superior granularity and robustness, preventing unauthorized access even if files are moved or renamed, but it requires a steeper learning curve to manage the complex abstraction of security contexts.
SELinuxLinux kernel security module
AppArmorLinux kernel security module
As of 2025, 55.6% of enterprise Linux environments actively enforce either SELinux or AppArmor. The choice is often dictated by the underlying distribution, though significant shifts occurred recently:
SELinux Dominance in Traditional Enterprise : With Red Hat Enterprise Linux (RHEL) holding 43.1% of the enterprise server market, SELinux remains the default for the largest segment. A major shift occurred in February 2025 , when openSUSE (Tumbleweed and Leap 16) switched its default from AppArmor to SELinux, citing the need for stronger type enforcement in high-security setups. This signals a broader industry trend toward SELinux for new deployments in regulated sectors.
AppArmor in Cloud and DevOps : Ubuntu (33.9% market share) and Debian default to AppArmor, making it the dominant MAC framework in public cloud environments (60%+ of instances) and containerized workloads. Its path-based model aligns well with immutable infrastructure and rapid container spin-up/down cycles. However, some cloud providers, like Microsoft Azure (in Azure Linux 3.0), are moving toward SELinux-only support for Kubernetes nodes to leverage its stricter isolation.
SELinux vs AppArmor enterprise adoption trends
View all
SELinux is the preferred choice for high-security and compliance-driven environments (e.g., government, defense, finance). It natively supports Role-Based Access Control (RBAC) and Multi-Level Security (MLS) , allowing for complex policies like "read-down, write-up." Studies indicate a 60% reduction in privilege escalation incidents in SELinux-enforced environments compared to permissive modes.
AppArmor provides robust application confinement sufficient for most general-purpose and web server scenarios. While it can implement RBAC via PAM modules, it lacks native MLS. Its strength lies in reducing the "blast radius" of compromised applications with significantly less configuration complexity, though it is theoretically easier to bypass via path manipulation (e.g., symlinks) if not carefully configured.
Both modules introduce negligible overhead in macro-benchmarks (typically <5% ), but differences appear in micro-benchmarks and operational management:
audit2allow , sealert ), contributing to a reported skills gap where 41% of IT departments struggle to find qualified administrators.SELinux vs AppArmor performance and management experience site:reddit.com
View all
| Feature | AppArmor | SELinux |
|---|---|---|
| Model | Path-based (Application-Centric) | Label-based (System-Centric) |
| Complexity | Low (Easy to learn/manage) | High (Steep learning curve) |
| Granularity | Moderate (File/Network/Capabilities) | Very High (Type Enforcement, MLS, RBAC) |
| Default Distros | Ubuntu, Debian, SUSE Linux Enterprise (legacy) | RHEL, Fedora, CentOS, openSUSE (new) |
| Profile Format | Human-readable text | Compiled binary modules |
| Best Use Case | Cloud, Web Servers, General Purpose | High-Security, Compliance, Multi-tenant |
| Overhead | Lower (Fewer hooks, simpler checks) | Slightly Higher (Complex label checks) |
Recommendation : Stick to the distribution default to ensure vendor support and tested configurations. Choose SELinux if you require strict compliance (PCI DSS, STIG), multi-tenancy, or are in the RHEL/openSUSE ecosystem. Choose AppArmor for faster deployment, easier management, and if you are heavily invested in Ubuntu/Debian cloud environments.
A.I. generated answers, verify all the facts."
I'm very interested in this topic—because I also see it as a way to set up parental controls. Yesterday I took a look at the built-in parental control tool (malcontent) and noticed that it isn't at all designed to block apt applications, only flatpaks. That's a joke! There are many preinstalled apt programs listed, and you can click on them, but the program doesn't block them for children at all...
Edit: Hm...Maybe I made something wrong yesterday because I had not enabled the parental control in the user profile of the "child". I just tested it again, and this time it worked with the apt packages. But I noticed when you e.g. disable libre office calc, you don't have access to libre writer or other libre office apps.
The malcontent isn't aimed at apps but the internet. So you have a Browser installed, but a Standard user identified in Malcontent cannot launch the browser because it does not show up under Internet. However when I tested it on Zorin 17.x, Remmina remote was still showing!
In malcontent you can select many apps.
The parental controls really seem to be suitable only for young children, because you can easily bypass them, for example, by pressing Alt+F2 and launching the programs using their terminal commands. This works even if the apps and the terminal are locked.
You can disable it in the child's session with
gettings set org.gnome.desktop.lockdown disable-command-line true
The terminal works by pressing Ctrl+Alt+T even when the terminal is locked for the child.
And even when the browser is locked, the child can setup a keyboard shortcut in the settings app and launch the browser with a keyboard shortcut.
Malcontent might be designed for GNOME, which doesn't have a traditional start menu, because locked apps can no longer be found using the search function, in the list of installed apps, or in the Activities overview. However, the apps that appear on the right side of the Zorin menu (Software, Settings, Zorin Appearance, Nautilus) can still be opened by clicking on them, even if they are locked.
It would help to set the zorin-menu layout to APPS_ONLY or APP_GRID or to set layout 3 or 4 in Zorin appearance.
That app is not really safe.
To make it safer change the layout of the zorin menu or disable Zorin menu (e.g. by selecting layout 3 or 4 in Zorin appearance - but then you would also need to lock Zorin appearance for the child afterward).
Also disable the run command and the terminal.
Disable alacarte (main menu) because with alacarte the child can easily create new launchers for the apps it likes, e.g. the browser or terminal, even when the apps are locked.
When the settings app isn't locked, the child can set up keyboard shortcuts for all apps it want, even for locked ones. So it would help to lock the entire settings app or at least to remove the shortcut for the terminal and lock the settings for the keyboard shortcuts with a custom lockdown dconf profile which makes it a bit more difficult to bypass the children protection.
It could do with similar function that murena have done with /e/OS 3.0 and up on Fairphone devices. Even if a child tried a factory reset they would not be able to access any social media apps etc.
The informations about apparmor profiles sound really difficult..That's way beyond my current abilities.
Yep, me too. Just imagine being a Systems Administrator! 