ReaR must not carelessly 'source' files

[jsmeix]

See https://github.com/rear/rear/pull/3203#issuecomment-2063439858 (some cases are clear like 'source default.conf' but some cases look rather obscure)

An attempt to generically mitigate it was not accepted, see https://github.com/rear/rear/pull/3258

See also the related issue https://github.com/rear/rear/issues/3260

[jsmeix]

@rear/contributors

A (rather artificial) example how ReaR would source user-controlled files by accident, cf. https://github.com/rear/rear/issues/3260#issuecomment-2219790045 and https://github.com/rear/rear/issues/3260#issuecomment-2219801028 and https://github.com/rear/rear/pull/3258#issuecomment-2180230626

In particular I do not know what could be possible
for "git clone" things done by whatever user and
stored under arbitrary directories and then
"just run" that via 'sudo' or something like that.

On the one hand I think it is not ReaR's task
to protect 'root' against any foolish things.

But because ReaR is meant to be run as 'root'
I think we must implement some reasonable protection
to avoid at least too obviously bad things
which can be easily avoided.

When I wrote that I had in particular Ubuntu users in mind where I fear some may carelessly "sudo COMMAND" all the time.

Right now I did:

johannes@localhost:~> git clone https://github.com/rear/rear.git
Cloning into 'rear'...
...

johannes@localhost:~> mv rear rear.github.master

johannes@localhost:~> cd rear.github.master

johannes@localhost:~> vi etc/rear/local.conf
...

johannes@localhost:~/rear.github.master> su
Password: ...

localhost:/home/johannes/rear.github.master # usr/sbin/rear mkrescue

"rear mkrescue" just worked with user-controlled files because all ReaR scripts and etc/rear/local.conf belong to "johannes users".

You could have - if you were interested - tried that on your own to reproduce and experience it yourself.

Of course now you may tell me that this case is root's own responsibility and his own fault to do 'su' carelessly and run user-controlled stuff but (again and again) you miss my point.

My point is not that this example shows how root could fool itself.

My point is that this example proves that there is absolutely noting in ReaR that checks at runtime if what ReaR executes is trustworthy.

Again and again - but unfortunately it seems you do not yet pay sufficient attention to what law (at least German law as far as I understand what it means) mandates from each of us personally - my fundamental reson behind all that is what I described in https://github.com/rear/rear/issues/2967#issuecomment-1498627825 and https://github.com/rear/rear/issues/2967#issuecomment-1510856524

It is left to the reader as an exercise to find more examples (perhaps even actual threats that can be exploited right now) where ReaR "just executes" files from non-trusted users.

[jsmeix]

For comparison with my SourceTrustworthy implementation from https://github.com/rear/rear/pull/3258

johannes@localhost:~/rear.github.master> git checkout jsmeix-SourceTrustworthy
...
Switched to a new branch 'jsmeix-SourceTrustworthy'

johannes@localhost:~/rear.github.master> su
Password: ...

localhost:/home/johannes/rear.github.master # usr/sbin/rear mkrescue
Refused 'SourceTrustworthy /home/johannes/rear.github.master/usr/share/rear/conf/Linux-i386.conf' because file owner 'johannes' is not in TRUSTED_FILE_OWNERS
ERROR: 
====================
BUG in usr/sbin/rear line 749:
Failed to Source /home/johannes/rear.github.master/usr/share/rear/conf/Linux-i386.conf
...
Terminated

Of course verly likely my current SourceTrustworthy implementation is not yet a final ultimate solution but (hopefully) it could be at least one step forward into the right direction compared to endless high-level theoretical questions that I can never answer properly so that all decays and dies out in nowhere land since a few month (I think decay started in April)

[schlomo]

I'd like to clearly take the problem of "security of developer environment" out of scope for this topic. I'd assume that developers only run sudo ./usr/sbin/rear mkrescue on test systems.

I'd also like to take all means of deploying ReaR from source out of scope, meaning the problem of users using git clone to get ReaR and then running it. Or downloading an archive of ReaR from GitHub and running sudo ./usr/sbin/rear mkrescue.

For me the scope is a production system where ReaR was installed via package (including the packages we provide on our GitHub releases page). And on this production system and a subsequently used recovery system we can think about potential attack vectors that ReaR can be part of.

[jsmeix]

@schlomo !!!

Please follow our instructions that we tell our users:

http://relax-and-recover.org/documentation/getting-started

No excuses!

[schlomo]

Yes, this is a quick start and not a production deployment. I'm happy to add there that for production deployments people should use packages. Quick start is for a first user to quickly see something happening, nothing more.

[jsmeix]

Possibly we have some kind of "all-clear" signal for ReaR:

I think meanwhile I found sufficient evidence which shows that "all other software" behaves basically same as ReaR currently does. Details will follow later because currently things are under investigation via a SUSE internal bug report that I filed.

So (at least for now) I downgrade this issue on from "blocker" to "enhancement" but still with "critical / security / legal" scope.

[jsmeix]

@schlomo I would change that "quick start" guide to do all as 'root' and explicitly describe that the local "git clone" must be under root's control to avoid to cross a privilege boundary from 'root' who runs usr/sbin/rear to a non-root user by sourcing ReaR's bash scripts when those scripts were downloaded under control of a non-root user.

[jsmeix]

Regarding https://github.com/rear/rear/issues/3259#issuecomment-2220492231

It does not really matter if a security issue exists "for a first user to quickly see something happening" or in a "production deployment". Both "first user" environments and production environments should be reasonably secure.

Those 'sudo ...' commands in our quick start guides indicate it is in particular meant for Ubuntu users what they could do on their (home) systems. I think we should provide in particular those users (who are presumably often rather unexperienced) some reasonably secure quick start guide.

[jsmeix]

All found cases where ReaR sources files were checked via https://github.com/rear/rear/issues/3260 and its subsequent issues https://github.com/rear/rear/issues/3285 and https://github.com/rear/rear/issues/3319 so this issue itself is no longer "critical/security/legal" according to what I wrote in https://github.com/rear/rear/issues/3260#issuecomment-2355205283 and I also move the milestone of this issue to 'ReaR v3.1'

[jsmeix]

@didacog I dared to also assign you to this issue because your contribution would by much appreciated in particular regarding "sourcing remote files".

[pcahyna]

I would like to unblock the issue by proposing a viable path forward.

The issue does not have a high priority for me (cf. "downgrade this issue on from "blocker" to "enhancement" " https://github.com/rear/rear/issues/3259#issuecomment-2227955337 ) but it would still be good to have an idea how to progress.

My starting point is the observation that "all other software" behaves basically same as ReaR currently does. (Another starting point is abandoning the "same-author policy" idea from https://github.com/rear/rear/issues/3260#issuecomment-2220864142, as there is has been no follow-up to explain it.)

So, other software executes potentially untrusted code all the time.

The shell executes commands that it finds in essentially arbitrary directories.

The Python interpreter loads modules again from essentially arbitrary directories.

The dynamic linker (ELF binary interpreter) loads shared libraries from essentially arbitrary directories and so on.

How are security issues prevented in these systems?

It is not by using any "same-author policy" (no software I know about is doing that), it is by controlling the set of directories that the code can be loaded from.

The shell uses $PATH, the Python interpreter sys.path, the dynamic linker uses its defaults and the directories configured in /etc/ld.so.conf and so on.

If any of these sets contain a world-writable directory, the security impact is disastrous and it is a job of the distribution and of the system administrator to ensure that this is not the case. (. got removed from the shell $PATH to prevent one of such issues.)

Moreover, if higher security is required, there are usually mechanisms to restrict the set of directories and prevent altering it.

For the shell, it is the restricted mode (see "The Restricted Shell" in the Bash manual, especially:

the following are disallowed or not performed: • Setting or unsetting the values of the ‘SHELL’, ‘PATH’, ‘HISTFILE’, ‘ENV’, or ‘BASH_ENV’ variables. • Specifying command names containing slashes. • Specifying a filename containing a slash as an argument to the ‘.’ builtin command.

).

For the dynamic linker it is the "Secure-execution mode", see the Secure-execution mode section of the ld-linux.so(8) manual page.

Basically, this is the observation at https://github.com/rear/rear/issues/3260#issuecomment-2219801028

Currently the only "line of defense" is the file name. E.g. /etc/os-release is hopefully safe to be read.

and my point is that this has been actually pretty sufficient in other software, so why not do the same in ReaR.

So, my proposal is:

Let SourceTrustworthy (or whatever the safe source wrapper function would be named) check the name of the file to be sourced and have a list of allowed directories to source from.

Furthermore, I believe that there should be multiple source wrappers for different use cases.

In particular, one for the shell-style config files (#3203) that should contain no executable code, and another for internal ReaR scripts that are called as part of the ReaR's shell scripting framework.

These are two very different use cases and it makes sense to keep them separated (for the former we may use a restricted shell, this makes no sense for the latter).

For the former the set of allowed directories should be system directories like /etc, /lib and /usr, while for the latter it should contain $SHARE_DIR.

There may also be a third command to source ReaR's config files, as this falls into neither category, with yet another set of trusted directories ($CONFIG_DIR).

Perhaps there could be even a generic source wrapper for sourcing scripts that are not part of ReaR, but do not fall under the "shell-style config files" category.

Such details can be added or adjusted according to the needs.

[pcahyna]

@didacog can you please specify what is the "sourcing remote files" functionality that you need? I am not sure whether it will fall under the same umbrella.

[jsmeix]

@pcahyna regarding "sourcing remote files" see https://github.com/rear/rear/issues/3294

[github-actions[bot]]

Stale issue message

[jsmeix]

With https://github.com/rear/rear/pull/3424 merged this issue should be "fixed/solved/done" at least to some reasonable initial extent.

With https://github.com/rear/rear/pull/3424 merged there will be regressions when third-party scripts use '.' for sourcing because currently sourcing via '.' is always forbidden in ReaR.

I would like to wait a bit and see if sourcing via '.' is sometimes actually needed in practice. If sourcing via '.' is sometimes needed, I will further enhance things to make sourcing via '.' again possible for the user by explicitly specifying in another config array which specific file paths he allows to be sourced via '.' by ReaR.

I could not wait because this regression is a bug in ReaR because 'source' is not POSIX compliant because '.' is the POSIX standard command so ReaR must not forbid using '.' in any case but allow it when really needed so I implemented trusted sourcing via '.' in https://github.com/rear/rear/pull/3434

[jsmeix]

With https://github.com/rear/rear/pull/3424 merged my other attempts in my 'jsmeix-SourceTrustworthy' and 'jsmeix-source-wrapper' branches should now be obsoleted. I will check those branches if they are completely obsolete and if yes I will remove them in the next days.

[jsmeix]

I closed https://github.com/rear/rear/pull/3379 and https://github.com/rear/rear/pull/3258 as superseded by https://github.com/rear/rear/pull/3424 and I deleted the outdated and superseded branches 'jsmeix-source-wrapper' and 'jsmeix-SourceTrustworthy'.