1 |
Ühel kenal päeval, L, 29.07.2017 kell 12:58, kirjutas R0b0t1: |
2 |
> On Sat, Jul 29, 2017 at 11:17 AM, Mart Raudsepp <leio@g.o> |
3 |
> wrote: |
4 |
> > Ühel kenal päeval, L, 29.07.2017 kell 13:20, kirjutas tuxic@posteo. |
5 |
> > de: |
6 |
> > > The task is already accomplished :) with a mixture of WM-based |
7 |
> > > hotkey definitions and a delayed commandline utility (main,scrot, |
8 |
> > > imagemagick). |
9 |
> > > Addtionally I dont think that my X11 uses framebuffer (not shure |
10 |
> > > about that, though)... |
11 |
> > |
12 |
> > Those tools work by using an inherent X11 security hole by reading |
13 |
> > out |
14 |
> > the root window, it's not relevant to framebuffer in the kernel |
15 |
> > sense. |
16 |
> > |
17 |
> > Note that you can't use a global shortcut key in X11 while a |
18 |
> > typical |
19 |
> > right click context menu is open, because these take a X11 grab and |
20 |
> > even screen lock can't activate.. Then only the delay approach will |
21 |
> > work (if desired then together with a shortcut if the shortcut key |
22 |
> > is |
23 |
> > hit before opening the context menu). Fortunately in this case you |
24 |
> > only |
25 |
> > wanted a dropdown in firefox, which isn't implemented like that. |
26 |
> > This popup menu problem is solved with Wayland (most importantly |
27 |
> > the |
28 |
> > not screenlocking aspect of it), but so is the root window security |
29 |
> > hole, so the compositor/WM needs to take the screenshot and tools |
30 |
> > like |
31 |
> > import/scrot won't work. |
32 |
> > |
33 |
> |
34 |
> I'm not really sure it is fair to call that a security problem. It's |
35 |
> intentional, and that is because there are plenty of things that need |
36 |
> access to the whole desktop at once. E.g. automating anything that |
37 |
> doesn't expose a development API or have an accessibility API can |
38 |
> pretty much only be done by scraping the contents of the screen - |
39 |
> these programs simply don't work in Wayland? That seems like a |
40 |
> misfeature. |
41 |
|
42 |
I'm calling things as they are. |
43 |
It is intentional only to the point of it not having been a concern |
44 |
back in the 1980s during X11 protocol designing. |
45 |
|
46 |
Any program running under the user can see the whole contents of their |
47 |
screen - not just their own; that's how these screenshotters work too, |
48 |
but it's easy to think of more nefarious use cases. |
49 |
|
50 |
Any program running under the user can listen to all key events meant |
51 |
for any other X application - that's how global shortcuts from random |
52 |
daemons or whatnot work (instead of DE provided hooks). It is trivial |
53 |
to write a key snooper. |
54 |
|
55 |
Now yes, this is local issues, so hopefully you are good on remote |
56 |
access issues, but if not, it might be game over for your terminal |
57 |
entered ssh passwords or whatever. There exist some mitigation |
58 |
techniques in the form of some non-standard X modules and other means, |
59 |
but they are usually not used and also can break such non-nefarious |
60 |
tools that make use of these aspects. |
61 |
Due to it being local (unless you for some reason enable TCP for X.org |
62 |
or something...) you can probably not worry about it too much, but it |
63 |
doesn't change the fact that they are security issues to the core of |
64 |
X.org, carried over from the 1980s. |
65 |
|
66 |
|
67 |
To solve these things in Wayland, there are cross-desktop protocols |
68 |
being specified to achieve these in a more arbitrated, correct and |
69 |
secure manner. There is proper isolation between applications. |