Bug 1150336 - AUDIT-1: roccat-tools: review of setgid directory /var/lib/roccat
AUDIT-1: roccat-tools: review of setgid directory /var/lib/roccat
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Marcus Rückert
E-mail List
Depends on:
Blocks: 1150189
  Show dependency treegraph
Reported: 2019-09-11 12:17 UTC by Matthias Gerstner
Modified: 2020-09-02 15:27 UTC (History)
5 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Gerstner 2019-09-11 12:17:59 UTC
+++ This bug was initially created as a clone of Bug #1150189
Like discussed in the proactive security team we want to catch up with
packages installing set*id items that haven't been whitelisted yet in the
permissions package. Formerly this rpmlint check type didn't cause badness and
therefore didn't require packagers to actually have them reviewed.

roccat-tools is one of the packages installing a setgid directory that isn't
currently whitelisted:

/var/lib/roccat drwxrws--- from roccat-tools-5.7.0-1.7.i586.rpm

The secure use of this directory needs to be reviewed and if all is good a
whitelisting entry in all our permission profiles must be added.
Comment 1 Matthias Gerstner 2020-03-03 12:53:54 UTC
The plan with roccat-tools seems to be to share the profiles in /var/lib/roccat between multiple users. Every user who want to use the tools needs to be a member of the roccat group.

The fun thing then is that all sub-directories and files created by the GUI tools below the directory also have mode 2770 or 0660 respectively. This means every member of the roccat group may modify and manipulate the profiles that other users may be using.

Since this seems to be an explicit use case that roccat-tools are considering this is quite a serious security issue. Some of the controllers here also allow setting key macro sequences of up to ~450 key strokes. This would even allow a kind of code execution injection.

The files stored in the sub-directories are plain binary files from C data structures written to disk. This might even allow further attack surface like stack buffer overflows and similar.

Furthermore sub-directories can be replaced by symlinks, causing the tools write profile data in arbitrary other locations. Since the file names are mostly fixed it's difficult to construct a successful attack, however. On write symlinks are replaced.

I'm keeping this bug private for the moment and I will report to upstream my concerns. A quick fix on our side would be to simply replace the /var/lib/roccat prefix by /home/$user/.roccat and be done with it.
Comment 2 Matthias Gerstner 2020-03-12 11:05:58 UTC
I'm assigning this to you darix, or is there a chance matthias@mailaender.name
can take care of this?

I want to add the settings for /var/lib/roccat tools to the permissions
package. For this to work you must first drop the roccat user, however. And
the you need to invoke %verify_permissions et al in your spec file. Afterwards
I can add the whitelisting entry.
Comment 3 Matthias Gerstner 2020-05-18 13:12:29 UTC
roccat-tools got deleted from Factory via sr#800517, because it failed to
build for a long time (because the whitelisting wasn't in place).

This was not the intention of the security team. The whitelisting requires the
changes depicted in comment 2, however. When you want to re-add the package to
Factory then feel free to adjust the package and re-open this bug.
Comment 4 Matthias Mailänder 2020-09-02 15:27:45 UTC
This software is unmaintained as the original developer resigned. No new hardware support will be added. https://www.reddit.com/r/linux_gaming/comments/5js1l2/im_stefan_achatz_stopping_programming_linux/