https://bugzilla.suse.com/show_bug.cgi?id=1226083
https://bugzilla.suse.com/show_bug.cgi?id=1226083#c3
--- Comment #3 from Wolfgang Frisch ---
OBS project: server:database/valkey
Upstream: https://github.com/valkey-io/valkey
Original upstream: https://github.com/redis/redis
We concluded our initial review. Due to the size and complexity, a full audit
of valkey was not feasible at this point. We focused our review on a few key
points:
- differences from the original redis
- sysctl settings
- systemd unit
- file system permissions
- default config
### Differences from the original Redis
valkey-7.2.4 is an exact copy of redis-7.2.4. The first differences arise with
(this) release 7.2.5. We went through the complete diff and found no obvious
security-related changes. Most changes are just debranding and API
compatibility fixes.
There were a few commits missing in valkey-7.2.5 (compared to redis-7.2.5):
- Missing fix for: https://github.com/redis/redis/issues/12864
- Missing unit tests for: https://github.com/redis/redis/pull/13004
- Missing bug fix:
https://github.com/redis/redis/commit/b3aaa0a1362d229ba1ecd44629655f76c77304...
- Missing bug fix:
https://github.com/redis/redis/commit/bad33f8738b4be5f58c4439a0c78312e4afbe4...
- Missing bug fix:
https://github.com/redis/redis/commit/1e8dc1da0de0add40d56fcbab9b64a3c5e61b6...
As far as we can tell, none of this is security-related. OK from a security
PoV.
### sysctl settings
The two sysctl settings are identical to Redis.
It's a bit unfortunate that `vm.overcommit_memory=1` is set system-wide just by
installing this package. As it was already noted by mgerstner in another bug,
it would be an improvement
to just set this sysctl option in a systemd unit, when valkey is actually
started. If valkey ran as root, it would be simple with
```
ExecStartPre=sysctl vm.overcommit_memory=1
```
However, since the valkey service (correctly) drops its privileges, this would
have to be implemented in a separate systemd unit.
Not a problem from a security PoV though. OK from our side.
### systemd unit
Upstream's systemd unit lacks systemd hardenings and doesn't drop privileges by
default but fortunately the (open)SUSE package ships its own much improved
systemd. Good!
I tested a few additional hardenings with no apparent problems:
```
--- valkey@.service.orig 2024-06-11 11:13:59.169323953 +0200
+++ valkey@.service 2024-06-06 20:26:20.000000000 +0200
@@ -8,8 +8,6 @@
User=valkey
Group=valkey
PrivateTmp=true
-# added automatically, for details please see
-# https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort
ProtectSystem=full
ProtectHome=true
PrivateDevices=true
@@ -20,7 +18,11 @@
ProtectKernelLogs=true
ProtectControlGroups=true
RestrictRealtime=true
-# end of automatic additions
+MemoryDenyWriteExecute=true
+RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
+RestrictNamespaces=true
+RestrictSUIDSGID=true
+
PIDFile=/run/valkey/%i.pid
ExecStart=/usr/bin/val
```
```
--- valkey-sentinel@.service.orig 2024-06-11 11:15:04.960116608 +0200
+++ valkey-sentinel@.service 2024-06-11 11:15:35.650486709 +0200
@@ -8,8 +8,6 @@
User=valkey
Group=valkey
PrivateTmp=true
-# added automatically, for details please see
-# https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort
ProtectSystem=full
ProtectHome=true
PrivateDevices=true
@@ -20,7 +18,11 @@
ProtectKernelLogs=true
ProtectControlGroups=true
RestrictRealtime=true
-# end of automatic additions
+MemoryDenyWriteExecute=true
+RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
+RestrictNamespaces=true
+RestrictSUIDSGID=true
+
ReadWritePaths=/etc/valkey
PIDFile=/run/valkey/sentinel-%i.pid
ExecStart=/usr/bin/valkey-sentinel /etc/valkey/sentinel-%i.conf
```
It would be great if you could include these changes, even though they're not
strictly necessary. We will whitelist the package either way.
### File system permissions
No problems here. OK.
### Default config
Valkey's default config is well-documented with sane defaults.
- Binds to localhost only by default. Good!
- In all cases where the user is asked to create files or directories, correct
file system permissions are mentioned. Good!
## Summary
We might conduct an in-depth audit in the future, but for now we can safely
whitelist this package.
--
You are receiving this mail because:
You are on the CC list for the bug.
