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

List:       kmail-devel
Subject:    Re: Fwd: possible security problem in kmail 1.6
From:       Andreas Pour <pour () mieterra ! com>
Date:       2004-02-15 22:07:32
Message-ID: 402FEDA4.DAA9C351 () mieterra ! com
[Download RAW message or body]

Ingo Klöcker wrote:

[ ... ]

Hi,

> > Understood.  But then in order to avoid deceiving the user, that
> > KMail in fact is closed, I strongly urge you to leave a window open
> > which states what KMail is doing (if the main window has been
> > closed),
> 
> Okay.
> 
> > prioritize doing the essential tasks (such as writing folder
> > indices)
> 
> That's not possible because after a message has been sent the index will
> change (because the sent message is then moved to the sent-mail
> folder).

Well you can write everything else.  It's a standard basic (not guaranteed as in
database transactions) transaction problem.  First you commit everything to disk
(the current state); then you do the send and update the folders and commit to
disk.

> And aborting a send is also not an option.

Sure it is - you just keep the mail in the queue folder for next startup.
 
> > and if the progress window is forced to close that you
> > immediately abort.
> 
> The sending progress dialog might have an Abort button for this.

Good idea!  The tricky thing is if someone explicitly kills the X window using
'xkill' or so . . . that should probably be treated as an abort.

> > At no point in time IMO should a password be cached and the user
> > given the impression it no longer is.  People should be able to, and
> > in fact do, share terminals :-).
> 
> Sharing terminals is not a problem. Sharing desktop sessions is. If
> people are too lazy to make use of the protection that multiuser
> operating systems like Linux or Unix provide that's those people's
> problem.

I agree with you generally, with the caveat that one should not "punish" users
for not understanding this, but I think this situation is different.  In the
first place, I do not consider myself a novice user, yet KMail's behavior very
much surprised me; in fact as I noted I think it's wrong b/c I do not expect,
even w/in a desktop session, for passwords to be cached after I close an
application.

If I share a session w/ someone, I expect them to have the user permissions
*locally* that I have; I do not expect them to share my network connections
after I close an app.  After all, why does KMail have a "save password" option
if you expect sessions (or user accounts) never to be shared?

Or think about a Kiosk or email garden scenario.

Or as another example, if I come to your house and borrow your desktop session
(as a friend) and use KMail, I don't expect that after I close KMail you have
access to my email account.

> It's not exactly difficult to run two different sessions with
> KDE and it's definitely easier to just lock your session than to close
> all applications that might hold confidential data, be it KMail or
> KWord or OpenOffice or whatnot.

If in fact it is KDE's position that desktop sessions cannot be shared b/c of
this type of vulnerability then I think we should make this fact well-known. 
But it seems even among the "core" people I am not the only one surprised by
this behavior . . . .  And I start to think that this might also be a problem
for kdesu usages by an admin, that somehow the root password is cached and
KUniqueApplication keeps it around after the root admin closes the window and
somehow this leads to an exploit . . . .

Ciao,

Dre

-- 
None are more hopelessly enslaved than those who falsely
believe they are free.
  -- Johann Wolfgang von Goethe
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel
[prev in list] [next in list] [prev in thread] [next in thread]