[Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Tvrtko Ursulin]

On 09/09/2015 05:26 PM, Maarten Lankhorst wrote:
> 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 at linux.intel.com> 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.

I am not even going that far, just talking about last frame stuck on 
screen. For me making that easier is a regression.

Tvrtko