Ubuntu hardening. Not a script. Just follow along and paste in the commands.
Last edited:
Ubuntu Hardening
- Thread starter Victor M
- Start date
Web site updated today. Private-etc firejail option is not compatible with Ubuntu 25 - you won't be able to connect to the inet.
Last edited:
@Victor M chatGPT mentioned an app to me yesterday, FlatSeal, might have some relevance for Ubuntu hardening?? I haven't installed it yet...
Yes FlatSeal is useful if you use Flatpaks. FlatSeal can let you minimize the connections between the flatpak and the outside world. You can freely experiment/disable what you see listed because there is a 'reset' button for when things don't work out.
Yes I installed Flatseal, and made some permission tweaks for one flatpak, so far
Thanks but too much this and that to apply. My Ubuntu is running fine as is....
And in case i can just restore back.
And in case i can just restore back.
I used to do that - image restore upon trouble. But then I realized that without Adding improved security that Matters, I would end up playing the game where I would restore and the attackers just returns again and again using the same attack method deploying different payloads. And my PC becomes their playground. WDAC App Control / fapolilcyd is a key defense that shackles the attacker from deploying hackware or any foreign exe. I know my red team has several attacks up their sleeve. But when they can't deploy their payload then I stay safe.
Last edited:
Just to mention, fapolicyd is less laborious to use than WDAC. With WDAC every time you wish to install something you need to permit the setup program and then permit the program itself. With fapolicyd, you install with apt as usual. And the apt database ( or dnf database on Fedora ) serves to drive exe enforcement. If the exe is in the database, it is permitted. Easy.
An attacker can stand up a keylogger using native Linux tools to log for your sudo password. That's why a Yubikey configured as sudo 2FA is an essential defense.
I will let Anthropic's Claude explain it:
==============================================================================================================================
The premise to discard first is that capturing the sudo password requires running a foreign binary. It does not. The dominant vector requires no new executable at all.
1. Shell-level sudo wrapping (the decisive vector). An attacker who can write to the account's shell startup files (~/.bashrc, ~/.bash_profile, ~/.profile, or the equivalent for zsh) can define a shell function or alias named sudo. When you next type sudo, your own shell runs that function instead of the real binary. The function prints a prompt indistinguishable from the genuine one, reads your password into a variable, records it, then transparently calls the real /usr/bin/sudo so nothing looks wrong. No file is executed that fapolicyd could inspect — a shell function is interpreted entirely inside a bash process that must, by definition, be allowed to run for you to have a usable session. Your custom interpreter-deny rules do not touch this, because there is no script file and no exec of anything in a writable path; it is bash reading its own builtins. A PATH-hijack variant using a script named sudo earlier in $PATH could in principle be caught by interpreter-deny rules if they block script execution from writable directories, but the function and alias variants have no such file and cannot be caught that way. This is why a password-only sudo is fundamentally phishable by any code running as your user, and it is the single strongest argument for a hardware second factor.
===============================================================================================================================
So, the wrapped sudo will capture the password and then the attacker can use it whenever he wants.
In other words, if you don't have a fingerprint reader that can be configured to use for sudo, then you should go buy a $27 Yubikey hardware token. Safeguards your Linux, and can be used for Google Advanced Protection of your gmail accounts, and can be used as phish proof 2FA for many web sites.
I cannot supply the PAM modifications required to setup sudo and login because they vary by platform, especially if you don't use Ubuntu which is this thread's focus.(and I know many readers don't ) Go ask your chatgpt. There will be 3-4 PAM files in /etc/pam.d/ to modify: sudo, console-login, graphical-authentication and graphical-login. And you will need to use a console logged in session on the side (ctrl-alt-functionkey) just in case you make a wrong modification and lock yourself out.
I will let Anthropic's Claude explain it:
==============================================================================================================================
The premise to discard first is that capturing the sudo password requires running a foreign binary. It does not. The dominant vector requires no new executable at all.
1. Shell-level sudo wrapping (the decisive vector). An attacker who can write to the account's shell startup files (~/.bashrc, ~/.bash_profile, ~/.profile, or the equivalent for zsh) can define a shell function or alias named sudo. When you next type sudo, your own shell runs that function instead of the real binary. The function prints a prompt indistinguishable from the genuine one, reads your password into a variable, records it, then transparently calls the real /usr/bin/sudo so nothing looks wrong. No file is executed that fapolicyd could inspect — a shell function is interpreted entirely inside a bash process that must, by definition, be allowed to run for you to have a usable session. Your custom interpreter-deny rules do not touch this, because there is no script file and no exec of anything in a writable path; it is bash reading its own builtins. A PATH-hijack variant using a script named sudo earlier in $PATH could in principle be caught by interpreter-deny rules if they block script execution from writable directories, but the function and alias variants have no such file and cannot be caught that way. This is why a password-only sudo is fundamentally phishable by any code running as your user, and it is the single strongest argument for a hardware second factor.
===============================================================================================================================
So, the wrapped sudo will capture the password and then the attacker can use it whenever he wants.
In other words, if you don't have a fingerprint reader that can be configured to use for sudo, then you should go buy a $27 Yubikey hardware token. Safeguards your Linux, and can be used for Google Advanced Protection of your gmail accounts, and can be used as phish proof 2FA for many web sites.
I cannot supply the PAM modifications required to setup sudo and login because they vary by platform, especially if you don't use Ubuntu which is this thread's focus.(and I know many readers don't ) Go ask your chatgpt. There will be 3-4 PAM files in /etc/pam.d/ to modify: sudo, console-login, graphical-authentication and graphical-login. And you will need to use a console logged in session on the side (ctrl-alt-functionkey) just in case you make a wrong modification and lock yourself out.
Last edited:
You may also like...
-
TuxTalk - Ubuntu 26.04 LTS - Tuxified !- Started by TuxTalk
- Replies: 43
-
Ubuntu MATE’s founder is stepping back after 12 years- Started by lokamoka820
- Replies: 1
-
Victor M Fedora 44 KDE Configuration- Started by Victor M
- Replies: 21
-
FUbuntu 26.04 LTS Leads Over Windows 11 In Creator Workstation Performance
- Started by ForgottenSeer 116559
- Replies: 3
-