[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KLineEdit Security
From:       Andreas Pakulat <apaku () gmx ! de>
Date:       2009-05-21 15:05:07
Message-ID: 20090521150507.GA23722 () neo ! apaku ! dnsalias ! org
[Download RAW message or body]

On 21.05.09 06:17:21, dantti85-dev@yahoo.com.br wrote:
> PolicyKit allows a better "containment" than using sudo
> since it can only do predefined tasks, but when the problems
> comes to key logging what the user is typing there not
> much that we can do to prevent it from becoming root.
> Well actually in my idea there is, i didn't get deep into details
> but i believe this could really work.
> 
> The idea is quite simple, when some application request
> a policy-kit authorization dialog for you prompting any
> password PolicyKit-kde would put some trash keys
> into the user password. For example
> The user pass is "banana";
> When he types b we fake type "@#FfDssfd3$", 
> then a and we again "dfsdflk"
> ....
> Then the "banana" password
> would be somehow lost in a very VERY long string.

Well, first of all you'd have to make sure that your somehow creating real
X11 events - at least - because a keylogger would sit at the X11 level
looking for Keyboard Events. This could be possible with the XTest library,
but I'm not sure wether those events really don't provide a way to find out
they're generated and not "original" events from the keyboard. Not sure if
that would really be enough, as it might be possible to directly read
events from the interfaces that the kernel provides and you're not going to
be able to fake those I think (unless the kernel provides an interface to
do that)..

Andreas

-- 
You have an unusual equipment for success.  Be sure to use it properly.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]