Op 09-09-15 om 18:15 schreef Tvrtko Ursulin: > > On 09/09/2015 05:07 PM, Daniel Vetter wrote: >> On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin >> <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: >>> It was just an example of a class of vulnerabilities which would be possible >>> with these changes. If they, as you said, will preserve the last frame on >>> screen when the compositor crashes. >> >> If your compositor crashes something should take over, either fbdev >> (which force-restores) or a new compositor (system one or just the one >> that crashed, restarted). And on modern userspace logind has copies of >> the fds which it uses to make sure priviledges (i.e. master rights) >> don't escape to the wrong person. > > The famous "should". fbdev is going out no? And attack just needs to prevent compositor from starting again. Or a bug somewhere needs to do that. Fact remains, before this = black screen, after this = last frame with bank details or similar. > > Change makes the scenario more likely, so what is the justification? Only that modeset is hard on framebuffer owner exiting? >>> For me this is serious enough not to go this route. >> >> If that doesn't happen you have yet another bug in userspace. I don't >> think there's a real problem really. > > If white hats had the imagination of black hats there would be no problems whatsoever. :) > > Tvrtko I have enough imagination, but the fact is the code to copy the fb contents requires the following: file_priv->is_master || capable(CAP_SYS_ADMIN) || drm_is_control_client(file_priv) If you already have any of those privileges you can draw your own fake TTY login screen and grab the password that way, so I don't see an additional attack vector exposed here. ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
