Allow restricting qubesdb write acccess on Linux#72
Conversation
|
This successfully builds on host-fc41, vm-bookworm, vm-fc42, vm-fc43, vm-fc44, and vm-trixie. It also appears to function properly in a Kicksecure 18 AppVM (new sockets exist with the expected names, |
e06409f to
2afb21d
Compare
|
You need to update selinux policy: |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026061502-devel&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026050504-devel&flavor=update
Failed tests56 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/176874#dependencies 21 fixed
Unstable testsDetails
Performance TestsPerformance degradation:14 performance degradations
Remaining performance tests:95 tests
|
2afb21d to
016661a
Compare
|
@marmarek I don't really know what I'm doing with SELinux policy, but I tried to do what looked right based on the existing policy files. Tested by installing built packages in a Fedora 43 DispVM; |
016661a to
0df1434
Compare
|
Suggestion: If you intend for this pull request to resolve the associated issue and would like for it to be linked to the issue automatically, you can put |
|
And once this is merged, do you insist on having it in R4.3, or R4.4+ is fine? |
|
@marmarek I guess that depends on how dangerous you think it is to apply to R4.3. If it could be backported to R4.3, that would be ideal, but if it comes with a significant risk of breaking people's systems, then we can probably live without it until R4.4+. |
Only users in the qubes group should be able to modify qubesdb, to prevent some forms of in-VM attacks where a malicious process injects crafted values into qubesdb that are then trusted by other processes in the same VM. Split the qubesdb access socket into two sockets; a privileged read/write socket and an unprivileged read-only socket. Also introduce an option that allows locking down the permissions on the read/write socket. In R4.3, we'll have to keep the existing, less-safe behavior by default to avoid a breaking change. Templates that can accept the risks of locking down write access can do so by setting the command-line option. For the sake of convenience, this is only done for Linux, Windows remains with a single "socket" for everything. Implements QubesOS/qubes-issues#10871.
dbd786c to
d755337
Compare
|
@marmarek Applied both fixes. (Thanks for your patience, been busy with work outside of Kicksecure/Whonix/Qubes OS for some weeks.) |
4 participants
Only uses in the qubes group should be able to modify qubesdb, to prevent some forms of in-VM attacks where a malicious process injects crafted values into qubesdb that are then trusted by other processes in the same VM. For the sake of convenience, this is only done for Linux, Windows remains with a single "socket" for everything.
Closes QubesOS/qubes-issues#10871.