Implications when mounting /home non-executable

Ask Fedora
, , , , ,
1

This article explains a use case for /tmp which is likely also useful.

I found it interesting that they specifically mounted /var/tmp to /tmp to add the parameters, why doesnt Fedora do that?

This serverfault comment explained the other parameters well.

I think nosuid is irrelevant when using noexec?

With the right parameters in the /etc/fstab you can block a big malware attack surface. The core problem is, that the /home is not protected, any program can write to the same location where things get executed.

I think this could also block the use of --user flatpaks, which I find problematic as they allow to install executable binaries without privileges.

But what are the results from this change?

  • ~/.bashrc, ~/.zshrc, ~/.config/fish/...
  • ~/.local/bin
  • ~/Random/Location/for/Appimages

Would these all not work? A shell config script is an executable, right? So it would not be loaded anymore. The bashrc includes this:

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

Does this mean, if the mutable ~/.bashrc cannot be loaded, the protected /etc/bashrc is also not loaded?

Fish does not have something like that at all, everything it in the unprotected ~/.config.

A place to put external things has to be there. Especially on Atomic, /usr/local/bin is not accessible, so /var/usrlocal/bin can be used.

What about Toolbox or Distrobox containers, these are in /var and would run, right?

For sure it will make testing software worse. And a lot of strange habits, like random install scripts, or… Appimages, would break.

But when using distro packages and flatpaks it should be no issue.

I see how nonexecutable, read, configfiles can still be an issue. And data theft is for sure still the biggest issue. But anyways I find the concept of nonexecutable unprotected locations very interesting. And the concept of how a Linux system is built (root is protected, users cannot access system, but the user data is unprotected) is pretty crazy.

Needing root access to do many of these installations is also a change. But this means more control, as currently anyone can run anything.

1 Like
2

I have never tried that but ~/.bashrc is sourced I believe. I don’t think it is normally executable.

The same for all the other shell config files.

Even a script you run manually doesn’t really need to be executable. You can use bash ~/myscript.sh.

I would think the bigger issues would be things you install and run from within your home directory or things that install themselves there. i.e. steam.

This is probably less of an issue on an Atomic variant though.

appimages would probably be the biggest problem on a Atomic versions I think.

There are ways to work around that though. For example, you could mount your appimage directory under home separately. Same thing for ~/.local/bin if you wanted to.

I am not sure how much that actually reduces your attack surface though.

1 Like
3

Damn forgot about the bash script.sh issue. True, I think you are right.

This makes things a lot easier but is really really problematic.

Appimages need a privileged manager that places them in something like /var/usrlocal/bin/.

A person on Lemmy showed me this:

It seems Appimages make progress finally, with signatures, sandboxing and a real package manager.

Needing one to install them is a feature not a bug. The issue with Appimages is that they work in completely random ways.

True this could be separately mounted. I mean if bash script.sh works anyways, why bother… this is such an issue it makes a lot just irrelevant.

If this can be mitigated (which might break your bashrc, YAY architectural problems!) then mounting nonexecutable would be more effective.

But that this works makes the first steps easier and less breaking.