Wrappers on Linux Workstations

As Linux Sys Admins, we are sometimes faced with dilemmas regarding what we can or cannot allow on machines.

Some functionalities are very important to users for their daily tasks and overall better use of their devices, but they sometimes also come with security concerns.
We came up with a way to still allow most of these functionalities, while having more control over them, but also their outcome.

While the Linux user community is technical, their missions are still quite heterogeneous. They can range from developers, sysadmins, network engineers and more…
And they all work with very different workflows (from front-end web to the low-level driver). Sometimes on the laptop, on a docker, on a local VM or remotely on a development VM. Some may even need to hook up via a specific hardware.

Which leaves us users who are very much used to having access to every aspect of their personal computers rather frustrated when they are too limited.

Combining Usability and Security

Wrappers are usually used for abstraction and convenience; they often are relied on to simplify command-line workflows, enforce consistent parameters, or adapt legacy tools to modern environments.
In the case at hand, they are used a bit more like “guardrails.”

Take, as example, package management. Tools like apt are powerful but inherently risky when misused (or maliciously used), and capable of altering a system’s status by removing critical dependencies, etc…
Instead of exposing these tools directly (or completely removing access to them), our team provides a wrapped version that preserves essential functionality, while explicitly blocking operations that could compromise the system’s integrity.

Why would our user base need access to apt? Why not just completely remove that option?

Since our user base is rather technical, and knows their operating system rather well in general, they should be able to install authorized packages, or to update or remove them whenever they like (even though we also have a daily, automatic updates running too).
Plus, if they encounter any basic dpkg/apt issue, it makes sense for them to be able to resolve them autonomously.

Here is the list of options we made available:

Usage:
ovh-apt <install|reinstall|remove|purge> [OPTIONS] <package|package=version> [package...]
ovh-apt <update|autoclean|clean>
ovh-apt <fix> (this executes apt-get install -f)
ovh-apt <fix-dpkg> (this executes dpkg --configure -a)
Examples:
ovh-apt update
ovh-apt install vim
ovh-apt install vim=2:8.1.2269-1ubuntu5.17
ovh-apt install --only-upgrade bash
ovh-apt fix

We also have a list of protected packages, to avoid having very useful ones deleted; firewall configuration, systemd, sudo, etc…
Basically, this includes everything that could have an impact on security or system integrity. As well, this wrapper in specific is non-interactive – in order to make sure a root shell is never offered – as can be the case natively with dpkg.

How to prevent specific packages from being uninstalled?

We have a .txt file containing a bunch of package names (one per line).
In our ovh-apt script, we look into that file, and if we find a corresponding package, we exit the script.

re="^(Purg|Remv) ([^ ]+) "
IFS="
"
protected="$(cat /etc/ovh/ovh-apt/protected.txt)"
apt_output=$(cat nohup.out)
for line in $apt_output ; do
if [[ "$line" =~ $re ]]; then
package="${BASH_REMATCH[2]}"
if [[ " ${protected[*]} " =~ [[:space:]]${package}[[:space:]] ]]; then
echo "Error: Package $package is protected, won't do."
cancel=1
fi
fi
done
unset IFS

There is more

By default, you would need root access on unix systems to be able to change the keyboard layout. We decided to make a wrapper to allow for some users to set the layout of their choice.
This implementation was also heavily requested by Linux users, and very understandably so.

Here’s how it works:

Usage: ovh-keyboard <command> [options]
Commands:
show -> Show current keyboard configuration.
set <layout> -> Update keyboard configuration.
Valid options: fr, us, gb, ca, es, it, de, pt

Just for funsies, here is the list of other wrappers we use:

ovh_backlightctl Allows user to control the backlight options of their monitors.
ovh_snap Allows users to manage a list of snap packages on their device protected
ovh_swapclean Obviously.
ovh-systemctl Allows specific and unharmful systemctl commands.
nmcli_wrapper Blocks the –show-secrets options with nmcli. ‘Cause we don’t want secrets to be seen (that’s why they’re secret).

We definitely will keep on using wrappers, whether it is for user or security needs, when the use case allows it. We find this way of handling the accessibility / security compromise fits quite well with how we manage the Linux parc so far.