[systemd-devel] [ANNOUNCE] systemd v230

[Zbigniew Jędrzejewski-Szmek]

On Sun, May 22, 2016 at 02:02:57PM +0500, Alexander E. Patrakov wrote:
> 22.05.2016 13:33, Alexander E. Patrakov пишет:
> >22.05.2016 03:51, Zbigniew Jędrzejewski-Szmek пишет:
> >>Hi,
> >>
> >>systemd v230 has been tagged. Enjoy!
> >>
> >>CHANGES WITH 230:
> >
> ><snip>
> >
> >>        * Framebuffer devices (/dev/fb*) and 3D printers and scanners
> >>          (devices tagged with ID_MAKER_TOOL) are now tagged with
> >>          "uaccess" and are available to logged in users.
> >
> >Has this been discussed with Wayland developers? Framebuffer device
> >access can possibly be abused to take screenshots and draw on top of the
> >compositor in a Wayland-based environment. Impossibility for arbitrary
> >applications to take screenshots was one of the design goals of Wayland,
> >and this change breaks it.
> >
> >So, unless one of Wayland developers confirms that they are OK with it,
> >please revert it and ask for a CVE.
> >
> 
> Sorry, I have to take this back. Attempting to grab video from
> /dev/fb0 here on Intel hardware, both under X and Weston, shows only
> an image from the first virtual console - i.e. not the actual
> session. Still, I would like someone else to confirm that this
> behaviour is not Intel-specific and cannot be circumvented by, say,
> ioctls on /dev/fb0.

Hi,

that change makes /dev/fb* behave the same as /dev/dri/card* and
/dev/dri/render*. You are right that the user can control the device,
this is by design: the processes of the same user are not isolated
from one another and can do pretty much anything. To achieve
isolation between processes running using the same uid some other
mechanism must be used (selinux, seccomp, etc). Wayland offers
separation between clients, but only when using the Wayland protocol,
and not through side channels.

>> Has this been discussed with Wayland developers? Framebuffer device

A few Wayland developers commented on the bugs where this was discussed.

Zbyszek