concerned about keyloggers and user account security

[secret resistor]

I somehow missed that:

But that is like saying ecryptfs is a security risk because if someone knows your password they can decrypt your home directory.

There are protocols in place to secure X sessions in a multi-user environment and they have been in place for many years.

If you disable them (as a user) or circumvent them (as root) they yes, like ecryptfs, X is a security risk, but, IMO, your argument is somewhat twisted.

The point is that the protocols that "secure X sessions in a multi-user environment" simply say who can have access to the session and who doesn't and everybody who does can do as they please. Which is why if you can run an X application in a given session you can snoop on the keystrokes from any other application regardless of the user running it. This type of all-or-nothing access controls is precisely the main problem being discussed here.

And I don't think the analogy to ecryptfs makes sense since with an encrypted file system you only give the key to the kernel and it will still enforce proper access controls for the non-root users. You don't need to give a potentially malicious application the key in order for it to access some files.

Also with regards to this:

Well, we would discourage such proof of concept discussions / posting of code here.

I can't say I agree with this since first you complain about me being "theoretical" and "paranoid" but then you object to me posting practical code. But it does say "forums admin" on your uniform , so I will respect that request with regards to posting actual code.

[Larkspur]

I was searching around to shore up my lack of knowledge on this. There's been a bit of discussion in the wake of "Linux GUI Security Circus," but little in the way of answers. I suppose the fact that attacks using xinput haven't been heard of is enough to not worry at the moment; as you and bodhi.hazen suggest, the vulnerability that allows xinput to be run maliciously has to come first.

I can't say I agree with this since first you complain about me being "theoretical" and "paranoid" but then you object to me posting practical code. But it does say "forums admin" on your uniform , so I will respect that request with regards to posting actual code.

Maybe you should file a bug on Launchpad explaining the potential risk, and see what the Ubuntu Security Team have to say. If you do, could you let everyone know what happens?

[secret resistor]

Yes, that blog post should probably be credited since it sparked the discussion. However, the problem is not confined to the XInput extension. I found two different pieces of code for a proof of concept XWindows keylogger, one using XQueryKeymap and another using XNextEvent to achieve the exact the same thing - receiving the keystrokes of any application using the same X session.

So, I think this isn't so much about XInput but rather going back to the root problem which is that XWindows, unlike the Linux kernel, is simply not designed to protect applications from each other. This apparently has been known for many years but I guess it's one of these things nobody wants to talk about, as somebody else already said in this thread. And again, it appears that SELinux has tried to address this but I am unsure of how successful it is and how practical it is to use it.

[gpost3]

Well, we would discourage such proof of concept discussions / posting of code here.

I agree with secret, we don't admire this comment. The proof of concept is already provided by secret. I can write the C++ code and simply run those commands in a binary executable for linux but our point here is to learn and "also" help improve Ubuntu (not destroy it) - as it is very clear non of us is ubuntu hater. Discouraging us to post the relevant code will not stop the immediate threats that a potential hacker will place upon us but infact it will create awareness for users to better understand the XWindows issue and protect themselves. Bad guy doesn't need ubuntu forum's admin permission to cause harm which is why he/she is bad to begin with. Ofcourse bodhi this does not void about what you said - to have strong password and use encryption for sensitive data, that still stands true and we thank you for it.

converts the keycodes to ascii characters. I can post a link to it but I don't know if I'm allowed to do that on this forum.

And that is very simple to do. One of my CS textbook has full chart for hex/dec/asc conversion table. :/ Regardless you don't even need that. 38 is the selstart for A. You can do a dynamic cast from (int *) to (char *) and get the asc code. As for lower cases, well 50 is the keystroke for shift. Very obvious that any key following 50 is actually in upper case whereas otherwise it is lower case.

As far as this type of vulnerability is concerned. You shouldn't really need apparmor or SELinux but a new iteration of XWindows. The idea is simple, only currently active/focused window should have access to key strokes. It just needs a simple branch condition to fix that in the composite design pattern (which is what is normally used in HCI - so I am quite sure XWindow has similar technique employed). I could write that patch for XWindows if I were a part of that team.

Having said that, even a hardware based keyboard encryptor won't work because the encrypted information would need to be decrypted at input service handler/interrupt (at the driver level) which makes the information available to all applications. The fix has to be made in XWindows. Someone should file this as a bug to Ubuntu/Canonical bulletin. I would like to see this addressed in next iteration. As for sysadmins who need this type of vulnerability, alternative downloads should be made available to them.

This thread made for a good healthy discussion. Thank you all. Ofcourse feel free to continue commenting.

[spynappels]

I agree with secret, we don't admire this comment. The proof of concept is already provided by secret. I can write the C++ code and simply run those commands in a binary executable for linux but our point here is to learn and "also" help improve Ubuntu (not destroy it) - as it is very clear non of us is ubuntu hater. Discouraging us to post the relevant code will not stop the immediate threats that a potential hacker will place upon us but infact it will create awareness for users to better understand the XWindows issue and protect themselves. Bad guy doesn't need ubuntu forum's admin permission to cause harm which is why he/she is bad to begin with. Ofcourse bodhi this does not void about what you said - to have strong password and use encryption for sensitive data, that still stands true and we thank you for it.

The reason it is discouraged is that this forum is visited by people with a whole range of abilities and motivations and is primarily a support forum. Anything which has the potential to cause problems when people who are not completely au-fait with what they are doing attempt to use the code is not permitted, along the same lines as why it is not permitted to post how to delete your /usr directory.
Technical discussions like this may be more suited to Launchpad, where closer co-operation with developers can be achieved if necessary.

[Soul-Sing]

The reason it is discouraged is that this forum is visited by people with a whole range of abilities and motivations and is primarily a support forum. Anything which has the potential to cause problems when people who are not completely au-fait with what they are doing attempt to use the code is not permitted, along the same lines as why it is not permitted to post how to delete your /usr directory.
Technical discussions like this may be more suited to Launchpad, where closer co-operation with developers can be achieved if necessary.

No, then you have to narrow the security subforum title. Sorry.
: Security Discussions:
"Discuss security flaws/updates/notices in the various Ubuntu releases."
So rather academic discussions are allowed and even encouraged.
This forum is visited by people with different "agenda's".No one can actively monitor these different agenda's.
Maybe restricting the subforum title is an option.

[spynappels]

No, then you have to narrow the security subforum title. Sorry.
: Security Discussions:
"Discuss security flaws/updates/notices in the various Ubuntu releases."
So rather academic discussions are allowed and even encouraged.
This forum is visited by people with different "agenda's".No one can actively monitor these different agenda's.
Maybe restricting the subforum title is an option.

Ok, I see where you are coming from, but the umbrella for this section of the forums is "Main Support Categories". Perhaps another subforum under "Other Community Discussions" would be a better place for discussions of this nature.

Note: I am not against these academic discussions, I feel they are very valuable, but they could simply cloud the issues in what is primarily a Support section of the Ubuntu Forums.

[gpost3]

So rather academic discussions are allowed and even encouraged.

Indeed and our domain for this thread is specifically Professional Practice in Computer Science.

Anything which has the potential to cause problems when people who are not completely au-fait with what they are doing attempt to use the code is not permitted

This argument is a bit twisted on the extreme end of the spectrum. Grocery stores still sell table knifes and that too can be misused by people with various abilities and motivations however that doesn't mean we despair 99% of the population who just want to cut their apples and oranges.

Note: I am not against these academic discussions, I feel they are very valuable, but they could simply cloud the issues in what is primarily a Support section of the Ubuntu Forums.

This makes sense. Perhaps we are too academic and this isn't the place to do it. I have created a section for this in launchpad and now I believe it is the right time to close this thread. Thank you everyone for your input and for being patient. I launched this thread, everyone commented (thank you) and now I am requesting it to be marked as closed.

Special thanks to spynapples, bodhi and secret.

[spynappels]

Indeed and not only are we discussing academia in a Computer Science context, we are also being very professional.



This argument is a bit twisted on the extreme end of the spectrum. Home hardware store still sells utility knifes and that too can be misused by people with various abilities and motivations however that doesn't mean we despair 99% of the population who just want to cut their apples and oranges.

I was not questioning anyone's professionalism, but the point still stands that this is primarily a support forum and it is hardly twisted to try and eliminate information which may alarm new users unecessarily or possibly cause problems if they execute code which they don't understand. There is absolutely a place for academic discussion, I'm simply not sure that a support forum is that place.

Edit: crossover post, good discussion all the same.

[gpost3]

There is absolutely a place for academic discussion, I'm simply not sure that a support forum is that place.

And I agree with you - this isn't the place for deep academic discussion. This thread should now be closed.
Cheers.