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

[Martin Gräßlin]

Am 2017-03-25 16:00, schrieb Fabian Vogt:
> Hi,
> 
> if I remember correctly, there's still no real consensus for a fix for 
> the two
> mentioned issues:
> 
> "kdesu kate" provides no visible feedback:
> This is IMO a general issue with kdesu, that console output is just 
> ignored.
> Displaying it if an application terminates within a second or so would 
> be
> ideal, but I don't know how hard it would be to implement.
> Yes, I know that kdesu by itself is not secure, but there are users out 
> there
> who use it and need some visible message that it's not secure. Not 
> doing
> anything is just not acceptable.

I'm sorry, but I don't find kdesu at all on my system...

kdesu kate
kdesu: command not found

> 
> kscreenlocker purges the clipboard: What about a config option that 
> enables
> the "show password" button? That fixes both my concern with the button
> existing and your concern with clipboard contents.

eh no, let's please not start the "let's add a config option for things 
we cannot decide on" mess.
It's as simple as restoring the clipboard content through klipper when 
the lockscreen ends. Your
suggestion needs changes, my suggestion needs changes. It just needs 
someone to do it. As I said previously: I cannot do the change in 
klipper as I'm on Wayland and klipper doesn't work there. But the change 
is trivial: take the screen locker watcher from KWin, include it into 
the build, remove the Wayland specific stuff and connect the deactivated 
signal to restore clipboard.

Cheers
Martin

> 
> Cheers,
> Fabian
> 
> Am Dienstag, 21. Februar 2017, 21:19:56 CET schrieb 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
>>