Suppose that I have started a console application which finishes, then shell prompt brings up again. But how can I be sure that it's the real command prompt? What if, for example, the application is a "key logger" which starts a fake prompt when I try to exit?
So, how can I detect that I am actually in a pure shell (eg. bash) prompt?
Technically, I will answer your question, ok. How you can ensure that you have come back to your shell? If you assume that the program is not malicious but you think it might run anoter shell, you can manually define a secret function with a secret content (that you will not export of course):
$ my_secret_func() { echo "Still alive"; } $ ~/Downloaded/dubious_program $ my_secret_func Still alive If dubious_program is malicious, it can easily trick you by passing on your input to the original shell and let it react. More generally, an unsafe executable has numerous ways to install a keylogger under your identity (and do many other malicious things), like installing itself in your ~/.bashrc for example. It could do so even if there were no visible effects — in fact, most malware tries not to have any immediate visible effect so as to minimize the risk of getting detected.
So, if your are not certain that what you execute is safe, either execute it with user nobody in a sandbox or don't execute it at all.
dubious_program wishes, it can fake the execution of my_secret_func. It takes a bit more work if my_secret_func was defined interactively rather than in the user's shell startup file (in which case it'll happen automatically), but there's no guarantee. /proc/.../mem? or something else? Of course there is no guarantee against such a directed attack. I just offer a solution for the standard type of malware that will just record what the user type and send it elsewhere. my_secret_func thing was no help against a malicious program, instead of letting the reader believe that it's useful. Compare PID of shell before and after running a command (same PID means same shell):
$ echo $$ 6215 $ bash --posix bash-4.3$ echo $$ 10230 bash-4.3$ exit $ echo $$ 6215 In the demo above, you can see me starting an application, in this case another bash in POSIX mode. Upon returning , we verify that the PID of the shell we use is the same, thus we can assume this is the actual shell. That of course can be automated by adding $$ to your shell prompt:
$ PS1="[$$] $PS1 " [6215] $ Variation on the theme can be done with checking a sha256sum ( or any other checksum , like md5) before and after. Sha-sums , if you don't know, are often used to check integrity of files, especially for downloads and iso images. In the demonstration below, we use /proc/<SHELL PID>/exe file, which is a symlink to actual binary (in this case , it would be my mksh shell). This way we can verify that the executable we're running is the same one.
[12107][xieerqi][21:34]: $ sha256sum /proc/$$/exe 70a16895186ddfac12343e816f05783cf60092c0980fc20c2ae4bc53b48f28e6 /proc/12107/exe [12107][xieerqi][21:34]: $ bash --posix bash-4.3$ sha256sum /proc/$$/exe c2615a71ff5c004e51aef248103a2950c25715f5eb8130837695770e1d78ecfa /proc/12434/exe bash-4.3$ exit [12107][xieerqi][21:35]: $ sha256sum /proc/$$/exe 70a16895186ddfac12343e816f05783cf60092c0980fc20c2ae4bc53b48f28e6 /proc/12107/exe As for key-loggers, they don't necessarily need to be inside shell. If you're using graphical terminal emulator, a key-logger can simply listen to the keystrokes being sent to any window, regardless of shell you use.
As far as shells themselves, it's possible to launch a process in background. For instance, shell scripts use ampersand like so command & to launch something in background. I'm not sure if a background process can still read keys, but the fact that shell exits isn't a guarantee that the app exited. In the small demo below, you can see a function being launched in background, the script seemingly exits, and yet the function still writes to out.txt every second.
[10754][xieerqi][21:12]: $ cat launch_background_app.sh #!/bin/bash run_in_background() { while true; do date +%s > out.txt sleep 1 done } run_in_background & [10754][xieerqi][21:12]: $ ./launch_background_app.sh [10754][xieerqi][21:12]: $ cat out.txt 1484280777 [10754][xieerqi][21:12]: $ cat out.txt 1484280778 [10754][xieerqi][21:12]: $ cat out.txt 1484280779 NOTE TO EDITORS: please don't remove the prompt from my example -it is there for demonstration purposes to show that shell PID remains the same.
P.S: security starts with installing a trusted application in the first place, so consider ensuring the integrity of the application before using it in the first place.
sudo privilleges - it opens up whole lot of door to whole lot of malicious things that can be done, not just keyloggers, but subverting sha256sum binary, other programs, installing rootkits without user knowing , etc. Malicious users can't anticipate everything, so such checks might works on some, might not work on those who do anticipate it A keylogger wouldn't try to fake a shell prompt, it would almost certainly leave behind a background process which monitors /dev/input or something similar (it will also try to hide itself in the process list). You're definitely looking at the problem the wrong way.
A common way of running untrusted binaries is to set up a virtual machine and run them there. Even that doesn't give you 100% safety, but it's often considered to be safe enough for practical use (of course, you won't run VMs with untrusted code on a production server or inside a protected network in a bank).
suspect-command; echo I am thinking of the number 43987 After the command exits echo will run. You should see the result on the line above the command prompt.
suspect-command runs something in background. echo might still echo out the text you gave it, but again - that's not a guarantee of safety. But yes, we could say it's a simple approach to testing whether you returned back to original shell.