This issue will be handled according to our disclosure policy outlined in
https://en.opensuse.org/openSUSE:Security_disclosure_policy

The information listed here is not public. Please
- do not talk to other people about this unless they're involved in fixing the issue
- do not make this bug public

In accordance with our policy we will make this issue public latest at
Internal CRD: 2020-06-17 or earlier at your discretion
This is the latest possible date and we prefer to make it public earlier if the
situation allows it. In that case we'll post a comment here setting the new
date.

You're free to make this public at any point but please inform us upfront.

(In reply to Johannes Segitz from comment #0)
> 132     local LOCKFILE="/tmp/.gnuhealth_backup.lock" # static tmp, arbitrary
> file creation, dos
>   133     local INFOFILE="/tmp/gnuhealth_backup.log" # static tmp, arbitrary
> file write
> 
> an unprivileged user can create /tmp/.gnuhealth_backup.lock and no backup
> will ever be created. Can also happen by accident.  
> 
> LOCKFILE and INFOFILE on systems with fs.protected_symlinks=0 can be used to
> overwrite arbitrary files.
> 
> INFOFILE might leak sensitive information, didn't check the content.

Any proposal to work around this? maybe move it to /var/lib/tryton/gnuhealth_backup.loc ? This directory is used by the Tryton/GNU Health Server

(In reply to Axel Braun from comment #2)
For the lock file a solution is to write it to /run. That directory isn't writeable by normal users and so you don't have a problem from a security POV. It's also tmpfs so sooner or later stale files are removed. If you write the pid of the running process in there you can additionally check if the process is still alive and recognize stale files

For the log file I would move it to /var/log and maybe only write it if necessary. Most of the time noone will look at it

Created attachment 833616 [details]
updated gnuhealth-control

As this lock file is just created for the backup-process, if can as well go to the directory created with mktemp - please review the attached script

(In reply to Axel Braun from comment #4)
1, LOCKFILE doesn't have any effect anymore. If it's not at a known location you can start as many gnuhealth-contol instances as you wish in parallel. Best use /var/run
2, INOFILE must be at a random location in /tmp or in a directory that's not writeable by a user (e.g. /var/log)

The fix for 1167126 is okay once the transport is changed to TLS.

(In reply to Johannes Segitz from comment #5)
> (In reply to Axel Braun from comment #4)
> 1, LOCKFILE doesn't have any effect anymore. If it's not at a known location
> you can start as many gnuhealth-contol instances as you wish in parallel.
> Best use /var/run

...you are right ....

> 2, INOFILE must be at a random location in /tmp or in a directory that's not
> writeable by a user (e.g. /var/log)

Ihave moved them to 

local LOCKFILE="/var/run/.gnuhealth_backup.lock"
local INFOFILE="/var/log/gnuhealth_backup.log"
 
> The fix for 1167126 is okay once the transport is changed to TLS.

OK, I will wait for the certificate.
Updated the original gnuhealth-control as well and will submit this in advance (and confidential) to upstream

(In reply to Axel Braun from comment #6)
Looks good, just change
local LOCKFILE="/var/run/.gnuhealth_backup.lock"
to
local LOCKFILE="/var/run/gnuhealth_backup.lock"
as a hidden lock file might cause confusion

and change
    touch $LOCKFILE
to 
    echo $$ > $LOCKFILE
that helps when you need to debug why this won't run (you see which process created the lockfile)

openSUSE-SU-2020:0490-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1167126,1167128
CVE References: 
Sources used:
openSUSE Leap 15.1 (src):    gnuhealth-3.4.1-lp151.2.11.1

openSUSE-SU-2020:0534-1: An update that contains security fixes can now be installed.

Category: security (moderate)
Bug References: 1167126,1167128
CVE References: 
Sources used:
openSUSE Backports SLE-15-SP1 (src):    gnuhealth-3.4.1-bp151.3.9.4

I think here all measures are implemented as well....

yes, thank you for fixing this

I have submitted some patches for GNU Health control, including some recommendations from openSUSE security assessment.

Some notes that you might want to consider for the openSUSE version of
the GH control center:

    Keep in mind that the standard GNU Health installation uses a non-privileged user ("gnuhealth"), so we don't use /var/run, /var/log, or any system directory. In addition, all Python dependencies are also installed locally, under $HOME/.local)

    The GNU Health update directory is static because we need to be able to have the latest update in case of issues and take it from there. So running in a pseudo-random directory or the use of mktemp is not suitable for this scenario.

    To avoid some user in the same server creating a file with the same location and name, thus preventing from running the backup, the new GNU Health control will create the temporary lock and info files in the gnuhealth HOME directory, so only the gnuhealth administrator will be able to access those files.

    We are using the mktemp with the prefix directory (/tmp) included (mktemp -d /tmp/gnuhealth-XXXX) . This makes it compatible with FreeBSD.

    Please use mktemp and assign it to a local variable in the "getlang" function scope. There is no need to create the directory in contexts other than installation of a particular language.

    Finally, we now delete the temporary directory after language

  installation process, regardless of the exit status.

The revision is at :
https://hg.savannah.gnu.org/hgweb/health/rev/a56e504fc120

And the GH 3.6.4 raw file:
https://hg.savannah.gnu.org/hgweb/health/raw-file/a56e504fc120/tryton/gnuhealth-control

Have a great weekend!
Luis