| |||||||||||||
DRI3000DRI3000Posted Feb 12, 2013 9:36 UTC (Tue) by renox (subscriber, #23785)In reply to: DRI3000 by alankila Parent article: LCA: The X-men speak
> I can't see a way to usefully constrain random application's behavior such that this couldn't ever be a problem.
Having the display server setting the tittlebar instead of the application is a start with server side decoration. Provided there is a 'secure' way for the display server to have such information of course..
> That's why security-conscious people invented the ctrl-alt-del keystroke combo that can't be caught by applications and which will always present the system log-on prompt.
A *very incomplete* solution, a trojan game could spawn a window looking like a webpage..
(Log in to post comments)
DRI3000 Posted Feb 12, 2013 11:42 UTC (Tue) by NAR (subscriber, #1313) [Link] Having the display server setting the tittlebar instead of the application is a start with server side decoration.Would this mean that my xterm wouldn't be able to print the prompt in the window title?
DRI3000 Posted Feb 12, 2013 12:51 UTC (Tue) by renox (subscriber, #23785) [Link]
>> Having the display server setting the tittlebar instead of the application is a start with server side decoration.
> > Would this mean that my xterm wouldn't be able to print the prompt in the window title?
By default yes.
DRI3000 Posted Feb 12, 2013 19:32 UTC (Tue) by jond (subscriber, #37669) [Link]
And what would the safe bit print? "xterm"? "X terminal emulator"? "/usr/bin/xterm"? "./a.out"?
DRI3000 Posted Feb 12, 2013 18:11 UTC (Tue) by tshow (subscriber, #6411) [Link]
> Having the display server setting the tittlebar instead of the application is a start with server side decoration. Provided there is a 'secure' way for the display server to have such information of course..
So my malicious application requests a window with no decorations and draws its own fake title bar. You have to allow undecorated windows unless you don't want to be able to do things like panels. There's no fixing this without breaking useful functionality.
DRI3000 Posted Feb 12, 2013 21:57 UTC (Tue) by renox (subscriber, #23785) [Link]
That's a good remark.
Either you loose transparent panels or implement some fixed functionality in the compositor (the way the screensaver is implemented in the compositor) or you need a way for the server to be able to distinguish between trusted clients and the other one, I don't know if this is possible..
DRI3000 Posted Feb 13, 2013 8:15 UTC (Wed) by ibukanov (subscriber, #3942) [Link]
> you need a way for the server to be able to distinguish between trusted clients and the other one,
It would be a big oversight in the design of wayland if the server could not do that...
DRI3000 Posted Feb 13, 2013 8:42 UTC (Wed) by renox (subscriber, #23785) [Link]
>> you need a way for the server to be able to distinguish between trusted clients and the other one,
> It would be a big oversight in the design of wayland if the server could not do that...
I don't know if this is a big oversight in Wayland's design or not,
DRI3000 Posted Feb 13, 2013 8:09 UTC (Wed) by ibukanov (subscriber, #3942) [Link]
> You have to allow undecorated windows unless you don't want to be able to do things like panels. There's no fixing this without breaking useful functionality.
One just need to restrict undecorated windows to few trusted applications that are a part of a secure GUI. Done right it would not restrict any useful functionality. For example, a trusted panel still can show status icons and notifications from untrusted applications. And even watching full-screen movies should be possible as window decorations indicating the trust level can appear on any user input.
DRI3000 Posted Feb 13, 2013 10:10 UTC (Wed) by tnoo (subscriber, #20427) [Link]
> One just need to restrict undecorated windows to few trusted applications > that are a part of a secure GUI.
How would this work in a tiling window manager (xmonad, awesome, etc)? These are so great because they don't waste any pixels on useless mostly decorations.
DRI3000 Posted Feb 13, 2013 10:18 UTC (Wed) by renox (subscriber, #23785) [Link]
It wouldn't work of course.
DRI3000 Posted Feb 13, 2013 10:53 UTC (Wed) by ibukanov (subscriber, #3942) [Link]
> How would this work in a tiling window manager (xmonad, awesome, etc)
Some pixels has to be wasted to provide fast visual clues about a trust level. With tiling one can try to color just one edge or a corner of the application in a semi-transparent way to communicate the trust.
Without always present visual clues for passwords one can try to require to press a special trusted key that brings a password-entering GUI that always properly decorate the window. But then one may forget to enter that special key...
DRI3000 Posted Feb 13, 2013 11:42 UTC (Wed) by tnoo (subscriber, #20427) [Link]
Practically, this won't be of much use. Most users don't care about this kind of stuff at all. Who actually checks every time the visual clues for secure connections given in a web browser before entering data?
There are even some people who provide their credentials (for bank or computer accounts) in emails from a "system administrator".
So, frankly, I don't think that the idea you advocate will be of much use in practice.
DRI3000 Posted Feb 13, 2013 12:37 UTC (Wed) by renox (subscriber, #23785) [Link]
> Who actually checks every time the visual clues for secure connections given in a web browser before entering data?
I do, thank you very much. With your reasonment one should remove those visual clues for secure connection? A bad idea.
> So, frankly, I don't think that the idea you advocate will be of much use in practice.
Being useful to those who do these checks is enough to make the feature useful in my opinion.
DRI3000 Posted Feb 13, 2013 12:24 UTC (Wed) by iq-0 (subscriber, #36655) [Link]
> Having the display server setting the tittlebar instead of the application is a start with server side decoration. Provided there is a 'secure' way for the display server to have such information of course..
You'd have to prohibit undecorated windows, transparent windows and full screen windows. All three can be used to create an illusion of a secure input prompt. And even then a basic attack with a maximized window that has in it's content pane something that looks like a secure input window would be enough to fool 80% of the users.
> > That's why security-conscious people invented the ctrl-alt-del keystroke combo that can't be caught by applications and which will always present the system log-on prompt.
The trick is that the special combo can't be grabbed by any normal program *and* that immediately all further input is only tied to a sort of secure input window that is always on top.
If no software can control the mouse or generate fake input for that dialog than it's a pretty sure way of making sure only the person controlling the real input devices is making the input and that that input is only received by the secure input window. And "training" people to enter some magic uncatchable key sequence before entering system credentials helps reduce the risk that they might type it into some malicious window.
This is one of the few things Microsoft did right with UAC. Before granting administrative privileges to a program a use has to press a button in a special popup that isn't visible by other windows programs and which can only be controlled using a few designated input devices (so a malicious program can't click the button itself).
They explicitly don't ask for credentials (so a program faking a security dialog would get no information). And credentials are only required for login and unlock (the "screwup" in this scheme is that a malicious program can pretend to be the login or lock screen and since they no longer train people to always press 'ctrl-alt-del' before login/unlock, there is no way of knowing whether you are typing in the real or a faked variant).
DRI3000 Posted Feb 13, 2013 13:04 UTC (Wed) by renox (subscriber, #23785) [Link]
You're right about the first point but you didn't get my second point: the special keycombo can only work for the native OS's credential, not for your bank's webpage that a trojan could make a look-alike, so that's an useful tool but a very incomplete solution.
DRI3000 Posted Feb 13, 2013 14:17 UTC (Wed) by iq-0 (subscriber, #36655) [Link]
Agreed. But solving that problem is solving the "trusted originator" problem.
This trick could be used to implement a ctrl-alt-del out-of-band validation scheme where a QR-code like tag in a webpage can be used to show a separately loaded website (with very explicit origin information and extra strict settings).
And it would be a light-weight alternative to using a separate device with a camera (and people are free to choose whichever they want to use for the OOB validation).
I'd really like Paypal or my bank to support such an optional validation of a transaction and having an implementation baked-in to the system would make for a very light-weight workflow and be a good deal better than the current variant (and an optional 2nd device out-of-band check for local malware problems and possibly even compromised local networks).
|
|||||||||||||