Re: [gentoo-user] Clickless screenshot...how?

[R0b0t1]

On Sat, Jul 29, 2017 at 1:17 PM, Mart Raudsepp <leio@g.o> wrote:
> Ühel kenal päeval, L, 29.07.2017 kell 12:58, kirjutas R0b0t1:
>> On Sat, Jul 29, 2017 at 11:17 AM, Mart Raudsepp <leio@g.o>
>> wrote:
>> > Ühel kenal päeval, L, 29.07.2017 kell 13:20, kirjutas tuxic@posteo.
>> > de:
>> > > The task is already accomplished :) with a mixture of WM-based
>> > > hotkey definitions and a delayed commandline utility (main,scrot,
>> > > imagemagick).
>> > > Addtionally I dont think that my X11 uses framebuffer (not shure
>> > > about that, though)...
>> >
>> > Those tools work by using an inherent X11 security hole by reading
>> > out
>> > the root window, it's not relevant to framebuffer in the kernel
>> > sense.
>> >
>> > Note that you can't use a global shortcut key in X11 while a
>> > typical
>> > right click context menu is open, because these take a X11 grab and
>> > even screen lock can't activate.. Then only the delay approach will
>> > work (if desired then together with a shortcut if the shortcut key
>> > is
>> > hit before opening the context menu). Fortunately in this case you
>> > only
>> > wanted a dropdown in firefox, which isn't implemented like that.
>> > This popup menu problem is solved with Wayland (most importantly
>> > the
>> > not screenlocking aspect of it), but so is the root window security
>> > hole, so the compositor/WM needs to take the screenshot and tools
>> > like
>> > import/scrot won't work.
>> >
>>
>> I'm not really sure it is fair to call that a security problem. It's
>> intentional, and that is because there are plenty of things that need
>> access to the whole desktop at once. E.g. automating anything that
>> doesn't expose a development API or have an accessibility API can
>> pretty much only be done by scraping the contents of the screen -
>> these programs simply don't work in Wayland? That seems like a
>> misfeature.
>
> I'm calling things as they are.
> It is intentional only to the point of it not having been a concern
> back in the 1980s during X11 protocol designing.
>
> Any program running under the user can see the whole contents of their
> screen - not just their own; that's how these screenshotters work too,
> but it's easy to think of more nefarious use cases.
>
> Any program running under the user can listen to all key events meant
> for any other X application - that's how global shortcuts from random
> daemons or whatnot work (instead of DE provided hooks). It is trivial
> to write a key snooper.
>

This is true but they are shared resources. You can add some hoops to
jump through but there will always be a shortcut that makes the
security system irrelevant as long as there is a user sitting down in
front of the computer running more than one process.

> Now yes, this is local issues, so hopefully you are good on remote
> access issues, but if not, it might be game over for your terminal
> entered ssh passwords or whatever. There exist some mitigation
> techniques in the form of some non-standard X modules and other means,
> but they are usually not used and also can break such non-nefarious
> tools that make use of these aspects.
> Due to it being local (unless you for some reason enable TCP for X.org
> or something...) you can probably not worry about it too much, but it
> doesn't change the fact that they are security issues to the core of
> X.org, carried over from the 1980s.
>

Again, you're baselessly calling these things security issues. That I
can see the entire screen or receive all key events is simply
necessary for a desktop to exist as people want to use it. You can add
restrictions that might affect newly launched programs but can have
more permissive settings configured for known programs, but this is
getting close to something like SELinux, which already exists, and
which people don't want to use because it is annoying.

If this is a security problem then the fact that process isolation
within a user ID pretty much does not exist is also a security problem
and a far bigger one that makes anything you might want to do
pointless. Any process running as you can just read and write
/proc/<pid> files or use ptrace to modify the state of another program
you are running. I don't need to see all key events to get your
password.

Every process is effectively running as the most privileged process
being run by the user who owns it. If you have a terminal open
somewhere that has a root login I could eventually synthesize
keystrokes to that process and run whatever I wanted to run. Do you
want to avoid this? Congratulations, you've invented mandatory access
control!

>
> To solve these things in Wayland, there are cross-desktop protocols
> being specified to achieve these in a more arbitrated, correct and
> secure manner. There is proper isolation between applications.
>

Do you have a link to this? How are they different from X's protocols?
What about programs associated with the same Wayland session? A lot of
potential "fixes" actually don't accomplish anything and just make the
system harder to use.

On Linux there really is no problem, because the display daemon is
separate from the kernel and from any normal user. That gives you as
much compartmentalization as you're going to get without modifying how
the kernel manages processes or installing a mandatory access control
system.


I think I should provide something to contrast the current state of X11/Wayland:

Windows had a terrible security issue stemming from daemon programs
being run in the equivalent of the same X11 session as the one used to
serve the user. There is a kernel space memory sharing IPC mechanism
based on window messages (like X11 events) that handles user input but
also some OS facilities because it's already in kernel space and can
access those things. The desktop session is the memory boundary in the
kernel for this IPC mechanism, so as daemons were run in the same
desktop as the user, I could post WM_TIMER to a system process and
supply code to be run when the timer expires, and have an asynchronous
procedure call be dispatched to the system process to run my code.

Microsoft responded that this was intended. In a sense they're not
actually wrong - it is next to impossible to prevent behavior like
this considering what a desktop is trying to be conceptually and they
published an advisory warning that every process in a desktop is
actually running as the most privileged process in that desktop. The
solution was to not run daemons in the same place that untrusted code
would be running:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn653293(v=vs.85).aspx.

It's also very poorly documented (fortunately) but it is actually
possible to have a Windows driver create a GUI directly. They made
this harder to do despite no public instances of it ever being done.


If you can't find similar design choices in Linux/X11/Wayland, that
means they're doing far better than average. Last I checked, sshd has
no presence on my desktop.

R0b0t1.