Systemd Reverts Its Stance On Letting Users Access Frame-Buffer Devices
Last week's release of systemd 230 ended up shipping with a change that made it more easy for processes running as a user to snoop on frame-buffer devices. That change has already been reverted for the next systemd update.
The systemd 230 + FBDEV issue was covered on Phoronix yesterday in Systemd 230 Opens Up A New Graphics Vulnerability & FBDEV Still Should Die. Basically, FBDEV devices are tagged with "uaccess" and made available to logged-in users. But the FBDEV API is insecure and could allow for other user processes to view the contents of the frame-buffer if making use of FBDEV such as with the X.Org Server fbdev driver or Wayland's Weston fbdev back-end.
The revert to their handling of FBDEV devices was made via this pull request that Lennart Poettering merged. He also commented, "I am pretty sure we shouldn't carry rules for such legacy stuff anyway. Or to say this differently: we should at least not add them anymore."
The systemd 230 + FBDEV issue was covered on Phoronix yesterday in Systemd 230 Opens Up A New Graphics Vulnerability & FBDEV Still Should Die. Basically, FBDEV devices are tagged with "uaccess" and made available to logged-in users. But the FBDEV API is insecure and could allow for other user processes to view the contents of the frame-buffer if making use of FBDEV such as with the X.Org Server fbdev driver or Wayland's Weston fbdev back-end.
The revert to their handling of FBDEV devices was made via this pull request that Lennart Poettering merged. He also commented, "I am pretty sure we shouldn't carry rules for such legacy stuff anyway. Or to say this differently: we should at least not add them anymore."
13 Comments