KPasswordEdit and security

[Kuba Ober]

On Tuesday 26 December 2006 17:47, Thiago Macieira wrote:
> Albert Astals Cid wrote:
> >> I *think* it is because you can set the password data to be in a
> >> locked memory page (so it won't be swapped out and written on the
> >> disk) when using a char *, but you can't do that with a QString,
> >> because QString controls the buffer, and there's no way for you to
> >> tell it it should use "safe" memory. I haven't looked at the code,
> >> though, so I don't know if this is happenning or not. IMO, having a
> >> password be swapped out to the disk would be an unacceptable security
> >> breach.
> >
> >I had a look to the code and did not found any call that seems to do
> > that, do you know how does one do that? (locking the memory page).
>
> It requires an mlockall(2) call, which is only possible in privileged
> programs. So we'd need all programs that use KPasswordEdit to be setuid
> root -- which our libraries don't allow.

Maybe at least locking just the page that contains the password buffer would 
help? Then no mlockall.

Of course the password lives in several places: the keystroke events are 
present in X server memory, the X library will have those too, and then Qt's 
event loops will also replicate those events. One imagines that the relevant 
network buffer and event queue pages from the xlib and Qt could be locked 
too.

Cheers, Kuba