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

[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.

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.

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
>