Hi Chris,
thank you for your reply.
On 06/15/2012 02:03 AM, Christoph Anton Mitterer wrote:
Hi.
First.... gpm has no bug tracker right? So could you please CC the
Debian bug, that we can record all this at some central palce? :)
As noted, didn't file Red Hat Bugzilla bug yet, since I am not completely
sure this is a security issue (and first wanted to obtain feedback from
gpm developers / upstream).
On Thu, 2012-06-14 at 11:06 +0200, Jan Lieskovsky wrote:
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677418
I've updated some information there:
Mainly that I think that ideally, a clipboard should be kept per logged
in user (and obviously each user should only get access to "his"
clipboard).
This includes, that a user's clipboard is removed one he has logged out
from all his sessions.
It does not mean, that there should be a clipboard for each terminal of
a user.
I don't see that far into gpm code. Maybe the callback handling paste-clipboard
event should check for UID (if it's the same as was used in the copy-clipboard
callback handler).
Have tested the reported behaviour in two different subcases:
1) try just two tabs, under each one of them logged in as different
user (under first one as 'root', under another as common, unprivileged
user). In this case the described behaviour works (IOW area selected
by root is paste-able by unprivileged user).
Note that this is of course not only a security hole between root/user-A
but also between user-A/user-B situations.
Sure, just focused on root/unprivileged user scenario in my testing.
But I would not consider this to be a trust boundary cross (security
issue). If you can login as root to some system, the fact that when
you log in to the same host as unprivileged user within the same application
isn't such a big deal.
I can't understand why you think this... especially on multi-user
systems it IS absolutely critical.
The system could be some terminal computer where people from many
different places can access a console.
Right, valid concern.
2) but tried also KDE's konsole vs Gnome's gnome-terminal (being logged in
as root in KDE's konsole, later login as unprivileged user to the same
host via gnome-terminal and try to paste the content). It still allowed
the unprivileged user to see the content of selected root area (content
of clipboard).
I don't exactly understand what you did there... gpm shouldn't work
within X at all, should it?
Didn't know about this restriction. But noticed now in gpm's manual page.
You think it should be considered a security issue or not? (IMHO gpm
should use separated clipboard for each of the users, so it would not
be possible one user to see the clipboards content of the other)
See my comments above, that go even a bit further...
Obviously session tracking would complicate things a bit,... one could
e.g. use consolekit for this, but that may be an unwanted dependency.
Didn't completely mean separated clipboard for each of the users (like
there would be another instance for each of them). Was rather thinking
of checking UID when pasting, if it matches UID used for copying (but
not sure this would be implementable). Will let gpm developers to reply
here.
From a "theoretical" security point of view, there should be no strict
need, to clear a user's clipboard when all his sessions are logged out.
Because an attacker that gains access to this (and could therefore read
the clipboard on subsequent re-logins) could probably also install
key-loggers or so.
But it may be helpful on systems where multiple persons share one
account (in theory each person should have it's own account, which is
why I wrote "theoretical" above)... an it's also the behaviour of X'
clipboard.
Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team
P.S.: Nico, Nikola could you let us know your opinion on the above?
(upstream view at the issue as a whole and possibilities how to
fix it [if willingness]).
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
