Bug 1183669 - AUDIT-TRACKER: CVE-2021-31153,CVE-2021-31154,CVE-2021-31155: please: security audit for permissions-file-setuid-bit
AUDIT-TRACKER: CVE-2021-31153,CVE-2021-31154,CVE-2021-31155: please: security...
Status: RESOLVED FIXED
: 1200665 1200666 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Matthias Gerstner
E-mail List
:
Depends on:
Blocks: 1200665 1200666
  Show dependency treegraph
 
Reported: 2021-03-17 19:06 UTC by ed neville
Modified: 2022-07-04 13:06 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ed neville 2021-03-17 19:06:14 UTC
Hello,

Would you mind performing a security review for me?

please is a memory safe sudo alternative that focuses on assigning rules with familiar regex syntax.

The pacakge is at https://build.opensuse.org/package/show/home:eneville/pleaser.

Upstream source is at https://gitlab.com/edneville/please

The message from the build service is:

[  174s] please.x86_64: E: permissions-file-setuid-bit (Badness: 10) /usr/bin/please is packaged with setuid/setgid bits (04755)
[  174s] please.x86_64: E: permissions-file-setuid-bit (Badness: 10) /usr/bin/pleaseedit is packaged with setuid/setgid bits (04755)
[  174s] If the package is     intended for inclusion in any SUSE product please open a
[  174s] bug report to request     review of the package by the security team. Please
[  174s] refer to
[  174s] https://en.opensuse.org/openSUSE:Package_security_guidelines#audit_bugs for
[  174s] more     information.

Thank you very much in advance.

Ed Neville
Comment 1 Johannes Segitz 2021-03-18 10:10:30 UTC
Interesting project. Do you plan to include this into openSUSE? Because only then the review is mandatory.
Comment 2 ed neville 2021-03-18 10:18:30 UTC
(In reply to Johannes Segitz from comment #1)
> Interesting project. Do you plan to include this into openSUSE? Because only
> then the review is mandatory.

Hello Johannes, yes please, I would like to get this included.
Comment 3 Matthias Gerstner 2021-03-22 12:23:40 UTC
This is written in Rust and consists of ~3.000 lines of code plus a big bunch
of vendor sources. Since I dealt with Rust code just recently I could take
over this one, too.
Comment 4 Matthias Gerstner 2021-03-30 11:44:19 UTC
I will start looking into this.
Comment 6 Matthias Gerstner 2021-03-31 13:01:19 UTC
Sorry I made a mistake when pasting my report and some lines went missing.
This is the full report this time:

I understand that you are the upstream author yourself so I will not reach out
to upstream about these results in other ways than in this here bug.

This my report:

 # Findings in `please`

 ## 1) Arbitrary File Existence Test and Arbitrary File Open via `-c`, `--check`

   Arbitrary file existence test and arbitrary file open as root is possible
   via the `-c`, `--check` command line switch. This does not involve an
   information leak but triggers kernel logic not usually available to regular
   users e.g. when sockets or special devices are involved. It also allows the
   setuid-root program to run out-of-memory. Examples:

     ```
     # runs OOM
     user$ please -c /dev/zero
     Killed

     # reads the full block device until OOM occurs
     user$ please -c /dev/sda
     Killed

     # this file exists (in my case)
     user$ please -c /root/.bash_history
     Error parsing /root/.bash_history:712
     Error parsing /root/.bash_history:716
     Error parsing /root/.bash_history:1380
     Error parsing /root/.bash_history:1382
     # this doesn't exist
     user$ please -c /root/.something
     ```

   The file existence test allows for a minimal information leak in terms of
   the involved line numbers output in the error messages.

 ## 2) Superfluous `ttyname()` calls

   The `tty_name()` function calls libc `ttyname()` on all file descriptors
   from 0 ... 255 until a result is achieved (or fails). This should be limited
   to the three standard i/o descriptors instead. Should not really be a
   security issue but this seems overkill.

 ## 3) Arbitrary File Existence Test via the `search_path()` function

   Arbitrary file existence test is possible via the `search_path()` function,
   called in please.rs:254. Examples:

     ```
     # this file doesn't exist
     user$ please /root/.something
     [please]: command not found

     # this file exists (in my case)
     user$ please /root/.bash_history
     You may not execute "/root/.bash_history" on mgtw as root
     ```

 ## 4) Arbitrary file existence test via the `-d` switch

   This one also allows differentiation between dirs and files.

     ```
     # here /root/.gnupg exists and is a directory
     user$ please -d /root/.gnupg cat /etc/fstab
     [<fstab content>]

     # here /root/.bash_history exists but is not a directory
     user$ please -d /root/.bash_history cat /etc/fstab
     Cannot cd into /root/.bash_history: Not a directory (os error 20)

     # here /root/.something does not exist at all
     user$  please -d /root/.something  cat /etc/fstab
     Cannot cd into /root/.something: No such file or directory (os error 2)
     ```

 ## 5) The Token Dir "/var/run/pleaser/token" is Created with Unsanitized umask

   The token dir "/var/run/pleaser/token", if not existing, is created via
   Rust's `create_dir_all` and the process's umask is not sanitized. This
   allows the unprivileged user to influence the resulting directory permissions:

     ```
     # the directory must not yet exist. If it does, a reboot can help out.
     test -d /var/run/please && echo "token dir already exists, won't work!"
     # clear umask
     user$ umask 0

     # run some arbitrary command, this needs to be allowed via /etc/please.ini
     # but whether the password is successfully entered or not is unimportant
     # at this point.
     user$ please cat /etc/fstab
     [please] password for user: ^C

     # now the directories should have been created world-writable
     user$ ls -lhd /var/run/please /var/run/please/token
     drwxrwxrwx 3 root root 60 31. Mär 13:48 /var/run/please/
     drwxrwxrwx 2 root root 40 31. Mär 13:48 /var/run/please/token

     # now to grant us access to arbitrary configured commands w/o entering the
     # user password
     user$ touch /var/run/please/token/$USER:`tty | tr '/' '_'`:$$

     # should now work w/o password
     user$ please cat /etc/fstab
     [<fstab content>]

     # since symlinks are also followed in the token directory we can now create
     # new world-writable files anywhere in the system after authentication
     # succeeds. Already existing files can be truncated to size 0 this way.
     user$ cd /var/run/please/token
     user$ rm -f $USER:*
     user$ ln -s /etc/tmpfiles.d/supersafe.conf $USER:`tty | tr '/' '_'`:$$
     user$ please cat /etc/fstab
     [please] password for user: <actual password>

     # the file should now have been created world-writable
     user$ ls -l /etc/tmpfiles.d/supersafe.conf
     -rw-rw-rw- 1 root root 0 31. Mär 13:57 /etc/tmpfiles.d/supersafe.conf
     # write some interesting content in there
     user$ echo "d /root 0777 root root -" >/etc/tmpfiles.d/supersafe.conf
     # reboot the local system e.g. via power button or display manager, then...
     user$ ls -lhd /root
     drwxrwxrwx 10 root root 4.0K 31. Mär 13:46 /root/
     ```

   So this more or less allows anybody who is allowed to execute at least one
   command with password authentication to perform a full local root exploit.

 ## 6) Check in `valid_token()` Based on the File Metadata's Time

   The check in `valid_token()` using only the file metadata may not be enough.
   This check is performed based on the realtime clock. It could be better
   to store a monotonic timestamp in the file instead. A user that is able to
   manipulate the system clock in some way (e.g. polkit rules) could this way
   extend its authentication time arbitrarily.

 ## 7) Fallback to '/bin/sh' for Execution of the Target Command

   The fallback to running the target command via '/bin/sh' in please.rs lines
   326 and 329 should be removed. If the direct execution fails then I don't
   see any valid scenario for trying it through the shell. This can only
   increase the attack surface. Although I don't see an easy attack vector on
   the spot it does give me a pretty bad feeling to see that.

 ## Findings in `pleaseedit`

 ## 8) Predictable Temporary File Names in /tmp and the Target Directory

   pleaseedit uses predictable paths in /tmp and in the target directory via
   the functions `tmp_edit_file_name()` and `source_tmp_file_name()` and
   possibly others. Without the Linux kernel's symlink protection this would
   allow arbitrary file overwrite and ownership change if a regular user is
   allowed to edit any file via pleaseedit.

   Here is an excerpt of system calls performed in /tmp when editing /etc/mytab
   successfully:

     ```
     statx(AT_FDCWD, "/tmp/pleaseedit.user._etc_mytab", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7fff21e4cd60) = -1 ENOENT (No such file or directory)
     openat(AT_FDCWD, "/tmp/pleaseedit.user._etc_mytab", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0100600) = 4
     chown("/tmp/pleaseedit.user._etc_mytab", 1000, 100) = 0
     fchmodat(AT_FDCWD, "/tmp/pleaseedit.user._etc_mytab", 0600) = 0
     execve("/usr/bin/cat", ["/usr/bin/cat", "/tmp/pleaseedit.user._etc_m"...], 0x5575afc490f0 /* 74 vars */) = 0
     openat(AT_FDCWD, "/tmp/pleaseedit.user._etc_mytab", O_RDONLY) = 3
     openat(AT_FDCWD, "/tmp/pleaseedit.user._etc_mytab", O_RDONLY|O_CLOEXEC) = 3
     unlink("/tmp/pleaseedit.user._etc_mytab") = 0
     ```

   So the `openat()` calls do not include the `O_NOFOLLOW` flag to explicitly
   protect against symlinks existing there. Furthermore these paths should
   really be unpredictable in an `mkstemp()` manner, whatever the Rust interface
   for it might look like.

   The `chown()` call would allow for a full local root exploit if not for the
   symlink protection mechanism. A race condition needs to be won, however,
   because the code tries to remove an existing file in this location first.

   In the target directory `pleaseedit` also potentially follows symlinks:

     ```
     openat(AT_FDCWD, "/etc/mytab.pleaseedit.copy.user", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0100600) = 4
     ```

   So if the target directory is under control of a non-root user then this
   could also allow privilege escalation, this time there isn't even symlink
   protection available, because the target directory will not be
   world-writable. It requires two user accounts to "work together", however,
   the user that is invoking `please` and the user that is owning the target
   directory.

 ## 9) Check whether the Target File is a Symlink

   In pleaseedit.rs:248 an attempt is made to check whether the target file is
   a symlink. This is a racy check, however. If the target directory is under
   non-root control then this situation may change at any time. Luckily, the
   `rename` system call doesn't support overwriting symlink targets. But if
   this check was intended as a security measure: it isn't one.

 # Non-Security Findings

 ## 10) Broken PAM configuration on openSUSE

   The PAM configuration currently installed with the package doesn't work on
   openSUSE. That is /etc/pam.d/please{,edit}. These files contain references
   to system-auth which is missing on openSUSE. You will need to refer to
   common-auth & friends instead. Otherwise PAM authentication won't work.

 ## 11) Explicit Password Processing

   Currently `please` reads in the password explicitly in `challenge_password()`.
   I don't think this is the usual approach, but instead you let the PAM
   framework decide what to display and what to query via the "pam conversion
   function" (see also `man pam_conv`). I think the same goes for the
   retry-loop if the password is wrong. It looks like `please` will currently
   always query for a password, even if the PAM stack wouldn't even require one.

 ## 12) Leftover Temporary Files

   In pleaseedit, if the editor exits non-zero, then tmp files remain unremoved
   (but at least with safe mode 0600). See pleaseedit.rs:318.

 # General Comments

 ## 13) Alternative Directories via `-d` switch

   Allowing to specify alternative execution working directories via `-d` by
   default is unsafe and probably unexpected. This could make a configuration
   entry that looks safe at first look actually unsafe. I think in `sudo` the
   default is to deny specifying a CWD unless explicitly allowed in the
   configuration.

 ## 14) Sanitazion of the Environment

   While the actual target command is executed with a clean and minimal
   environment, the setuid-root binary for itself is not cleaning up the
   environment. This should be done as one of the first steps to avoid any
   unexpected interactions with sub processes or library/framework components
   that interpret environment variables.

 ## 15) Design Regarding Privilege Dropping

   The currenty design of `please` runs with full root privileges most of the
   time and only drops them when something needs to be run explicitly with the
   real user privileges. This leaves a lot of attack surface. Actually it
   should be the other way around: The program should drop to the real uid/gid
   until it is clear that something needs to be performed with root privileges.

 ## 16) General setuid-root Considerations

   Designing a setuid-root binary is a difficult task. Using a modern
   programing language doesn't fix that, sadly. You need to be aware of a lot
   of system programing aspects to make it safe. A starting point could be this
   BSD man page outlining typical considerations to make in setuid-root programs
   [1].

   [1]: https://adam.shostack.org/setuid.7.html

 ## 17) Look at how Others do it

   Designing a general privilege escalation tool in the spirit of `sudo` is an
   even more difficult task than just writing an arbitrary setuid-root program.
   While I don't like all aspects of classical `sudo` myself it could be a good
   idea to study its source (sadly not that easy to follow, did it myself a while
   ago) and get an idea of all the caveats that need to be considered for this.
Comment 7 Matthias Gerstner 2021-03-31 13:04:07 UTC
This is now a private bug only visible to members of the SUSE security team
and people explicitly in the CC list of this bug. We will handle these
findings in private until you want to publish them.

According to our openSUSE disclosure policy the findings can remain private
for up to 90 days, resulting in a publication date no later than 2021-06-29.
Please let us know how you want to handle the publication.

A couple of the findings deserve CVE assignments, especially items 5) and 8).

Is your tool already in production use according to your knowledge?

If you want to add this to openSUSE:Factory then apart from fixing the
individual findings I would also like to see the improved security design as
outlined in comments 15) and 16) etc.
Comment 8 ed neville 2021-03-31 16:40:43 UTC
(In reply to Matthias Gerstner from comment #7)
> This is now a private bug only visible to members of the SUSE security team
> and people explicitly in the CC list of this bug. We will handle these
> findings in private until you want to publish them.

Please can you add me to the list of people who can see the report, mail it to 
me or let me know what I need to click in order to see it?

> According to our openSUSE disclosure policy the findings can remain private
> for up to 90 days, resulting in a publication date no later than 2021-06-29.
> Please let us know how you want to handle the publication.

I'd like to fix any issues and let distros get time to get packages updated 
before a publication please.

> A couple of the findings deserve CVE assignments, especially items 5) and 8).

I'm happy for you to take credits and generate the CVE if that's what you're 
used to.

> Is your tool already in production use according to your knowledge?

There's a few users according to Debian popcon.

> If you want to add this to openSUSE:Factory then apart from fixing the
> individual findings I would also like to see the improved security design as
> outlined in comments 15) and 16) etc.

Thank you for doing the review, once I see what you found then I get get to 
work fixing and then of course, hopefully inclusion in openSUSE:Factory.

Ed
Comment 9 Matthias Gerstner 2021-04-01 07:35:47 UTC
(In reply to ed neville from comment #8)
> Please can you add me to the list of people who can see the report, mail it
> to 
> me or let me know what I need to click in order to see it?

Hmm, it looks like comments that are marked private cannot be seen even by members in the CC list. I'm marking comment 6 as non-private now, hope that fixes it for you.
 
> I'm happy for you to take credits and generate the CVE if that's what you're 
> used to.

It's not much about the credits, rather to allow other users and integrators to become aware. When your tool is not that widespread than a single one for will suffice.
Comment 10 Matthias Gerstner 2021-04-09 10:19:17 UTC
Hi Ed, are you able to see the report now? Is everything clear to you? Do you
have any time frame when the issues will be fixed?
Comment 11 Matthias Gerstner 2021-04-14 07:24:18 UTC
I requested and received CVEs from Mitre as follows:

- CVE-2021-31153: cummulative for all file and directory existence tests
  corresponding to findings 1), 3) and 4)
- CVE-2021-31154: for the predictable temporary filenames in pleaseedit
  corresponding to finding 8)
- CVE-2021-31155: for the missing sanitation of the umask corresponding to
  finding 5)
Comment 12 Matthias Gerstner 2021-04-14 11:32:01 UTC
(In reply to matthias.gerstner@suse.com from comment #6)

So Ed has written fixes for the issues on the upstream branch "0.4rc" in
commit 453164202257fc3ddca93c6be7957e041e802c6c.

Follow-up review of the changes:

>  ## 1) Arbitrary File Existence Test and Arbitrary File Open via `-c`, `--check`

when -c is passed now then the given path will be processed with the real
uid/gid directly in the `general_options()` function. If -c is not given then
the fixed path /etc/please.ini will be processed with root privileges. This
should be okay.

Hint: Since you are now opening the target path with the real privileges you
can also print out proper diagnostic i.e. the errno when opening the file
fails. With the current code no error is printed and exit status is still zero
when the target file cannot be opened.

>  ## 2) Superfluous `ttyname()` calls

Only 0 .. 3 are checked any more in the `tty_name()` function.

>  ## 3) Arbitrary File Existence Test via the `search_path()` function

`search_path()` is now executed with the real privileges.

The error message is now always "You may not execute <path> on <host> as
<user>". This could be confusing in some cases where the user would indeed be
allowed to execute it, but the command in question is not installed. Similarly
to 1), since you are now checking with real user permissions, it would be okay
to output some more diagnostic about why the command could not be looked up.

>  ## 4) Arbitrary file existence test via the `-d` switch

`do_dir_changes()` is now executed with the real user permissions. If changing
the directory fails then the error message is always "You may not execute
<path> on <host> as <user>". Similarly as in 3) you could output more
diagnostics here.

I would consider, since `do_dir_changes()` runs after the authentication has
succeeded, that the function should be called with the *target* user
credentials. This would require considering item 13), however, to not allow to
specify a target directory by default, to avoid unexpected side effects.

>  ## 5) The Token Dir "/var/run/pleaser/token" is Created with Unsanitized umask

This is now fixed `create_token_dir()` and `update_token()` by temporarily
switching the umask to mode 0o077. While this fixes this specific security
issue I would recommend to drop the umask to a safe value for the complete
execution time of 'please' and only restore the original value when you are
about to run the target command or edit the target file.

This way you will prevent issues sneaking in in the future e.g. a logging
framework creating unsafe files or things like that.

>  ## 6) Check in `valid_token()` Based on the File Metadata's Time

The function now uses a new helper function `boot_secs()` which retrieves the
CLOCK_BOOTTIME time. This looks good.

>  ## 7) Fallback to '/bin/sh' for Execution of the Target Command

The fallback has been removed without replacement. Looks good.

>  ## 8) Predictable Temporary File Names in /tmp and the Target Directory

'pleaseedit' now creates unpredictable filenames that are explicitly generated
using random numbers. That should fix the issue, however I wonder if there
isn't some standard feature in Rust that deals with temporary files? Something
like tempfile [1] ?

[1]: https://docs.rs/tempfile/3.2.0/tempfile/fn.tempfile.html

There are still some issues with the temporary file handling. The current
system call sequence looks something like this:

```
statx(AT_FDCWD, "/tmp/pleaseedit.mgerstner.RcZpWVX9._etc_mytab", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffdff64a1f0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/etc/mytab", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0600, stx_size=3, ...}) = 0
openat(AT_FDCWD, "/etc/mytab", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/tmp/pleaseedit.mgerstner.RcZpWVX9._etc_mytab", O_WRONLY|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0666) = 4
chown("/tmp/pleaseedit.mgerstner.RcZpWVX9._etc_mytab", 1000, 100) = 0
fchmodat(AT_FDCWD, "/tmp/pleaseedit.mgerstner.RcZpWVX9._etc_mytab", 0600) = 0
```

The first statx() call is checking for existence of the temporary file which
stems from the following line in `setup_temp_edit_file()`:

```
if tmp_edit_file_path.exists() && std::fs::remove_file(tmp_edit_file_path).is_err() {
```

This existence test should be unnecessary since the filename is unpredictable
and the chance that it clashes with an already existing file should be near
zero. And if the file already exists then something is rotten and you should
not continue.

The second openat() call is creating the temporary file, however it is not
passing the `O_EXCL` flag. This means that in theory, if the file already
exists, that it would be re-used and not newly created. This should not be the
case.

Finally the `chown()` call is still problematic, because it operates on the
pathname, not on the file descriptor. If for some reason the temporary file
would be removed, then an attacker could once more put a file or symlink
under its own control in its place. This should be changed to `fchown()`.

>  ## 9) Check whether the Target File is a Symlink

This check was removed without replacement. Looks good.

>  ## 10) Broken PAM configuration on openSUSE

The new version seems to work correct in this regard. The configuration is
generated from the spec file.

>  ## 11) Explicit Password Processing

The new version no longer explicitly reads in passwords.

>  ## 12) Leftover Temporary Files

Temporary files are cleaned up now.

There is still something strange with pleaseedit, though. I use vim as an
editor and when `pleaseedit` runs it to edit the target file and I put vim to
sleep via ctrl-z then the terminal is broken. I think `sudo` create a PTY
device to communicate with the child process to make this work. This could be
something you can look into, after we finished this security report.

>  ## 14) Sanitazion of the Environment

pleaseedit now also cleans up the environment, in `please` this step still
happens pretty late, just before execution of the target command. It would be
better to do it before the first `set_privs()` call occurs. This could be
problematic with some special PAM modules, however, e.g. when environment
variables point to sockets for password managers or such.

>  ## 15) Design Regarding Privilege Dropping

There now exist `reset_privs()` and `eprivs()` to deal with privileges. This
is okay so far but I would reconsider the naming of these functions. They are
not very intuitive in my mind, I would prefer something clearer like
"esc_privs()" and "drop_privs()".
Comment 13 Matthias Gerstner 2021-04-16 12:39:49 UTC
I will wait with publishing the security report until you have a fixed version
released. Please let me know when you are ready.

Regarding bugfixes it would be helpful when you commit smaller changes. Commit
453164202257fc3ddca93c6be7957e041e802c6c on the 0.4rc branch was pretty hard
to to correlate to the individual issues.
Comment 14 Matthias Gerstner 2021-05-18 09:29:08 UTC
So Ed wrote me that Debian is also taken care of by now. We can publish
everything now.
Comment 15 Matthias Gerstner 2021-05-18 11:20:23 UTC
I posted a condensed report on oss-security:

https://www.openwall.com/lists/oss-security/2021/05/18/1

I also submitted a whitelisting for the setuid-root binary in Factory. You
should be able to submit your package to Factory now.
Comment 16 Matthias Gerstner 2021-05-18 11:20:43 UTC
Closing as fixed.
Comment 17 OBSbugzilla Bot 2021-05-18 11:50:03 UTC
This is an autogenerated message for OBS integration:
This bug (1183669) was mentioned in
https://build.opensuse.org/request/show/894035 Factory / permissions
Comment 18 OBSbugzilla Bot 2021-11-17 15:42:43 UTC
This is an autogenerated message for OBS integration:
This bug (1183669) was mentioned in
https://build.opensuse.org/request/show/931965 15.3 / permissions
Comment 19 Swamp Workflow Management 2021-12-02 20:21:20 UTC
openSUSE-SU-2021:1520-1: An update that solves three vulnerabilities and has 27 fixes is now available.

Category: security (moderate)
Bug References: 1028975,1029961,1093414,1133678,1148788,1150345,1150366,1151190,1157498,1160285,1160764,1161335,1161779,1163588,1167163,1169614,1171164,1171173,1171569,1171580,1171686,1171879,1171882,1173221,1174504,1175720,1175867,1178475,1178476,1183669
CVE References: CVE-2019-3687,CVE-2019-3688,CVE-2020-8013
JIRA References: 
Sources used:
openSUSE Leap 15.3 (src):    permissions-20200127-lp153.24.3.1
Comment 20 Andreas Stieger 2022-06-18 07:19:32 UTC
*** Bug 1200665 has been marked as a duplicate of this bug. ***
Comment 21 Andreas Stieger 2022-06-18 07:19:59 UTC
*** Bug 1200666 has been marked as a duplicate of this bug. ***
Comment 22 Andreas Stieger 2022-06-18 19:34:48 UTC
*** Bug 1200666 has been marked as a duplicate of this bug. ***
Comment 23 Andreas Stieger 2022-06-18 19:59:25 UTC
Reporter sais this was not actually applied to the distros?
security:idm/pleaser/15.3/x86_64
security:idm/pleaser/15.4/x86_64
Comment 24 Matthias Gerstner 2022-07-04 13:06:05 UTC
(In reply to Andreas Stieger from comment #23)
> Reporter sais this was not actually applied to the distros?
> security:idm/pleaser/15.3/x86_64
> security:idm/pleaser/15.4/x86_64

No it wasn't. The whitelisting was only requested for Factory up to now.

Please open a separate bug prefixed with "AUDIT-WHITELIST:" to request backports of whitelistings into individual products. Thanks!