What to do with potential workflow-changing / breaking changes?

[Martin Gräßlin]

Am 2017-02-21 20:39, schrieb Fabian Vogt:
>> > - Saving clipboard contents, restoring again
>> 
>> Pointless as we cannot restore in an app which is going to close down.
>> It needs klipper to be able to restore.
> 
> Is there no built-in API in QClipboard for that or is this the issue 
> that
> the clipboard on X11 is a weird shared buffer?

The clipboard content is gone when a window closes. That's the primary 
reason why klipper exists, that you have a history is just a side 
effect.

> 
>> > - Disabling pasting into the password field (event filter?)
>> 
>> That was my initial thought as well, but I didn't find anything in the
>> Qt API to achieve it.
> 
> Wouldn't an event filter capturing Ctrl-V (or however it is implemented
> inside Qt to determine the key combo) and middle mouse work?
> I'm not sure whether that works with QML, I'm still used to good ol'
> QWidgets...

yes, maybe. Maybe not. The filtering in screenlocker is already quite 
bad and we don't know in the screenlocker what's the input field. After 
all we load the ui through a look'n'feel package.

>> The diff has a problem: it's X11 specific without checking whether we
>> are on X11 (and that early we just don't know. On my system (modern
>> session) both WAYLAND_DISPLAY and DISPLAY are available.)
> 
> Yup, as it's not possible to run applications as root on wayland anyway
> I didn't bother to figure out something. By doing 2>/dev/null that
> should work sufficiently on wayland as well, using the cout fallback.

I'm extremely against adding X11 specific code to otherwise 
multi-platform applications.

We just make our lifes more difficult and that might bite us in the 
backside a few years down.

If we want to do something now, let's do it in a portable, 
multi-windowing system way and ignore the fact that right now it 
wouldn't work on Wayland anyway.

> 
>> I think the detection needs to go into kdesu(do). That would also 
>> ensure
>> that we detect the Wayland case which currently also just exits.
> 
> What about other methods of launching it? You mentioned polkit, for
> example.

Polkit is not for launching apps as root. It's for doing a certain 
action (e.g. saving a file as root).

I'm not aware of any other options except of kdesu(do) or the gnome 
version of it, which I don't think we care about.


> 
>> I just tried to see what happens:
>> kdesudo dolphin
>> Invalid MIT-MAGIC-COOKIE-1 keyQXcbConnection: Could not connect to
>> display :0
>> 
>> That is kdesudo/kdesu could detect whether the process directly failed
>> and show an error message: "Did you try starting a GUI application as
>> root? Several applications protect against it and disallow it. If you
>> want to edit a file consider using sudoedit..."
>> 
>> It would mean that we need to change kate to not return 0, but maybe
>> -EPERM?
> 
> As it's the goal to disallow applications from running graphically as
> root anyway, maybe kwin is the best place? I'm not too familiar with
> the X11 protocol, but maybe it's possible to detect a new X11 
> connection
> and display the warning message to the user and if he selects "Cancel"
> the connection is terminated.

Nope, we don't get this.

> There is a window between the connection getting established and the
> user making a decision, I'm not sure how critical that would be.

Well that's the point: that's too late. You can see this in my review 
request. It's of most importance to terminate the application prior to 
establishing a connection to the X server. As soon as the connection is 
opened we must consider the application as exploited. My attack against 
dolphin worked that way to directly interact with the window when it 
opens. That is when the x window is opened, not when the window renders. 
The result was that the first frame already shows konsole tab opened 
with a:
#whoami
root

As soon as we have a window we are completely exploitable through xprops 
on the window - I just assume that there is a string processing 
vulnerability somewhere in the stack. Also we cannot assume that the 
xserver is trusted: it might be a fake one, so just opening the 
connection is dangerous. Given the crash reports I get for KWin in 
string handling, I'm actually quite certain there is at least one 
possibly exploitable crash.

I highly suggest to watch 
https://media.ccc.de/v/30C3_-_5499_-_en_-_saal_1_-_201312291830_-_x_security_-_ilja_van_sprundel 
which goes into the detail of how insecure X is and why I consider 
opening just a connection to xcb is dangerous. The talk also mentions 
KDE software, but was wrong in that point (the mentioned software is 
secure). Nevertheless this talk is the reason that Qt forbids setuid 
applications.

Cheers
Martin