Security Experiment: Store executables in protected areas only

[boredsquirrel]

Storing executable files in unprotected areas is very dangerous. It requires that users can execute code from pretty random locations, with no portal, password prompt, signature verification or other security barrier.

This is an easy way to get malware.

The idea

Mount the home subvolume noexec and move all wanted scripts and binaries to /usr/local/bin aka. /var/usrlocal/bin (on atomic desktops)

Separate users

It begins with having a user with no admin access, and another one in the wheel group that you only use for rare admin tasks.

I will have to experiment with that, polkit and run0 should support it well, also solving flatpak install issues occuring with su.

Move all binaries and scripts

In KDE Dolphin and GNOME Files you can elevate a filemanager tab/process by entering admin:/ in the address bar. This uses polkit and allows you to move files without being using sudo or the terminal.

Problems

Python

What about python scripts and packages? These are normally

Unprivileged Containers

Containers stored in ~/.local/, I imagine Distrobox, could cause issues here.

This could mean

• .local needs to be mounted separately
• it then needs to be protected, for example with selinux-confined-users

Shell configs

I have a lot of .fish scripts in my local config folder, that include different aliases and functions.

Where can these be placed, that is a system location?

Afaik for bash you can place them somewhere in /etc.

Firefox binary

This affects all universal blue images, where they have blindly removed Firefox. If you use the tarball, there is an updater program that is only ran as the user. It would need to be patched to use a polkit prompt to place the updated firefox files in the privileged location.

Appimage, binaries etc.

Unlike Flatpaks or RPMs, these are normally placed in random locations.

Various Appimage managers use different approaches, you could use .local/bin but this is also an unprotected location.

Moving them manually to /usr/local/bin can work, but likely breaks manager programs, updates etc. Especially am would be a big loss, as the .zsync files and signatures are an important step ahead.

Gaps

You can run whatever scripts with bash scriptname.sh. There are likely similar things for other interpreters like python or other used shells.

What would be a way to block this?

I know that SELinux confinement blocks piping but not this, and it can likely break a lot.

[einer (One)]

Ok
So, the very 1st question is “Is the system a server or a workstation?”
.
.
and on it goes until you have enough information to develop a deployment and usage model for the specific case …
.
.
Then figure out what resources are needed/desired to make the system work for the user(s).
This then will guide you as to how and where to put the binaries such that they are used as “You/the system owner” intended. In an extreme case, you might put the user in a proper chrooted jail …

I guess what I am trying to determine is what specific use case(s) are you using for this “Experiment”?

[boredsquirrel]

I want a normal single or multi-user system where the need to have administrative rights is mostly not present, but if you like you can use polkit with a dedicated admin user in wheel without ever logging in.

The threat is other programs running malicious code, not users. The goal is a pretty normally working but better system, that makes more sense.

This means a lot of things might break, as I already listed above

• user flatpaks
• appimages, binaries, updaters
• shell scripts, configs
• python, cargo, go etc

[job79]

I expect this to also break rootless containers (stored inside ~/.local). Other things that I have in my home dir that would break are neovim plugins and git hooks. I don’t think this could be solved, creating another location that is writable and executable would defeat the purpose would it not?

I don’t really see what you are trying to achieve here? Mounting home with noexec would as far as I see it only result in a more complex and difficult to use system without much security benefits. It would make installing malware more difficult yes, but thats just because it would make executing anything from outside the repo’s more difficult.

Storing executable files in unprotected areas is very dangerous. It requires that users can execute code from pretty random locations, with no portal, password prompt, signature verification or other security barrier.

I think unprotected here just means unverified by fedora. In every other way the home directory should not be considered unprotected because it is the directory that contains the data that actually matters.

Signature verification is probably the way to go if you want to prevent users from executing malicious code, but that would be very difficult to setup in an open source ecosystem. Who would be giving out the signatures and who is going to pay them?

[boredsquirrel]

True! Also user virtual machine images, do you know if these are executable or just sourced?

In the end selinux-confined-users will be the only good solution, but maybe with mounting .local as a separate drive, executable, and protecting it?

Desktop Linux is such a mess…

[boredsquirrel]

@job79

more complex and difficult to use system without much security benefits

I disagree. Yes it would be more difficult, but RPMs and Flatpaks work. Manually elevating your privileges and placing things in protected areas is also still possible.

This simply means control and structure.

The problem is that we are able to do so much in random ways.

For example system flatpaks are managed by polkit and work rootless. There is no such thing for libvirt, maybe running it in a Flatpak (like with GNOME-Boxes or Fedora-Flatpak-virt-manager).

In short I want a Linux system more like Android, as Android is damn secure, EVEN THOUGH it is the most popular OS on the planet

[steppybug (Stephen Serafin)]

Currently I am running as a user without admin privileges and run VMs rootless and containers rootless. I am looking at custom images built with bootc to obtain a mostly read-only installation including executables.

The polkit paradigm is a compromise as it often elevates privileges to root even for users with no sudoers controls (ie: nm on multiuser host). I would rather leave it out of my bootc images.

As controlling what gets executed on a general purpose PC is not my idea of general purpose, how about systems that remain undamaged in spite of malicious code being run?

[grumpey (Joe)]

What’s the difference between this and setting more restrictive permissions on directories you want to restrict?

[boredsquirrel]

All programs run as the same user. So I dont know what permissions I could use, apart from maybe creating custom groups and chowning directories to these groups.

And then how do I run for example Distrobox as a normal user, without the hassle, but only allow it to write into the .local directory? I may be able to run it as a different user, but the whole user system is not really meant for this.

I already have a very big Flatpak override, so having .local separate and executable could work and be sufficiently secure.