I appreciate all of the feedback. As it stands we limit the end user to 1 app that's already launched and they're not supposed to be able to do anything else. Naturally, we're going to security in depth and want to make sure we're preventing damage at nearly all levels. Don't want to be the next Target hack were you lose everything because an HVAC company got compromised. :-) In some ways we've avoided SELinux because it seems like there aren't any experts out there or great documentation on it. Feel like we find more questions than answers in our googling. But we'll look into that.
Thanks again to everyone. ________________________________________ From: Jonathan Buzzard <jonat...@buzzard.me.uk> Sent: Wednesday, August 26, 2015 7:44 PM To: xrdp-devel@lists.sourceforge.net Subject: Re: [Xrdp-devel] rate limit keyboard input On 26/08/15 14:59, Steve Gula wrote: > My security people are concerned about a particular attack vector and we > haven't found anything on Google to help. I'm hoping someone here can - > > The concern is if someone is remoting into a machine we have 'locked > down' (stripped out a lot of packages/etc) and then they copy/paste or > use a keyboard emulator to retype an entire application into the remote > machine. For instance: > > Local machine: > Take executable binary and convert to hexadecimal for easy copy/paste > Install software that emulates keyboard and will retype entire contents > of the local machines clipboard (because we disabled copy/paste in xrdp) > connect to remove machine and create a file in remote home directory > Let software/keyboard emulator start retyping the entire executable > The convert to hexadecimal step is unnecessary, you just pipe STDIN to a file and go nuts on the keyboard. Pretty standard thing to do in hacking if you can get a remote shell and want to get an executable onto the system. > We think doing a keystroke logger on the remote end and pumping the logs > somewhere could help monitor part of it. But we'd really like to > rate-limit the incoming keystrokes because if the attacker aims too high > (re: large exploit file size) then we can at least delay the inevitable > and hope we notice in time. Particularly on the system in place where > keystrokes would be very minimal (essentially a kiosk driven largely by > mouse clicks). > > Any thoughts or input would be appreciated. > As Jay said the proper way to defend against this is Selinux, and mark all the directories that they can write to, as none executable. Then it does not matter what they can write to the file system. If you don't trust your users don't let them execute anything in the first place. A skilled hacker will be using hand crafted binaries written in assembler that are tiny compared to something written in C and compiled and may well slip under the radar of your monitoring anyway. JAB. -- Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk Fife, United Kingdom. ------------------------------------------------------------------------------ _______________________________________________ xrdp-devel mailing list xrdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xrdp-devel ------------------------------------------------------------------------------ _______________________________________________ xrdp-devel mailing list xrdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xrdp-devel
