Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there any possibility to authenticate a running process in Linux to be sure that this is the original/right one?

I know that an Linux operating system is only that secure like the way you use it. For Example: Lets say I'm using Ubuntu Linux and install any software via a PPA, that software get rights to do everything it want's in my system, because I have to install it with sudo rights. (PPA's are in general a security problem in Ubuntu I think)

Let us assume the "bad guy coded software" installs the things to do the work I expected, e.g a Gnome-Theme, a dynamic wallpaper whatever. But also it replaces any process of my Ubuntu system with a key-logger or any other kind of malware and runs in my system.

Is there any chance to check a running process in Linux if it is the original one?

The running processes are easy to get/find out and the processes of the OS and also the processes from a Ubuntu apt repository are known, so I guess there could be a possibility to compare the code of the running processes with any database of known Ubuntu repository software/processes and known Linux software/processes.

Is some kind of process authentication possible or available for Linux/Ubuntu?

share|improve this question
up vote 4 down vote accepted

You can know whether a file has been modified by checking a secure hash of it's contents. You can do this manually, or you can use your package manager; with RPM it's rpm -V, with apt you use debsums.

Then it's a matter of checking to see if the process was started using that file. That bit's simple as well: check the proc entry. This keeps track not only of the path to the file, but also its inode number, so if the file is replaced, it will not match. Observe:

[tylerl@tyler-11 ~]$ ./foo &
[1] 26157
[tylerl@tyler-11 ~]$ ls -l /proc/26157/exe 
lrwxrwxrwx 1 tylerl tylerl 0 2013-01-16 12:31 /proc/26157/exe -> /home/tylerl/foo
[tylerl@tyler-11 ~]$ ls -l /home/tylerl/foo
-rwxr-xr-x 1 tylerl tylerl 8.3K 2013-01-16 12:31 /home/tylerl/foo
[tylerl@tyler-11 ~]$ echo 1 >> foo
-bash: foo: Text file busy
[tylerl@tyler-11 ~]$ rm foo
rm: remove regular file `foo'? y
[tylerl@tyler-11 ~]$ echo 1 > foo
[tylerl@tyler-11 ~]$ ls -l /proc/26157/exe 
lrwxrwxrwx 1 tylerl tylerl 0 2013-01-16 12:31 /proc/26157/exe -> /home/tylerl/foo (deleted)
[tylerl@tyler-11 ~]$ ls -l /home/tylerl/foo
-rw-r--r-- 1 tylerl tylerl 2 2013-01-16 12:32 /home/tylerl/foo

Note two things: (a) the file can't be modified while it's running, and (b) while you can delete it and replace it, the new directory entry will correspond to a different executable, and the proc entry will say (deleted) to warn you of the difference.

Note that I could recover the original file just by running cp /proc/26157/exe ./orig_exe, and then I could examine it as necessary. Files aren't actually deleted from disk until the last reference is closed.

share|improve this answer
This is really helpful. The rpm - V (debsums for apt) are very nice tools. To check the file from which the process is started is a good point too. thx! =) – Jan Koester Jan 16 '13 at 20:14
Don't forget the libraries, see /proc/PID/maps for those. Related to that, there's another potential problem: code injection (not the input validation kind), see and for further reading:… – mr.spuratic Jan 17 '13 at 11:20

debsums can help but it's not the final answer.

For example a package could install an entirely new file in /usr/local/sbin, and then go through the .profile files of the users it finds and add a line to execute that process.

debsums would not complain, no file belonging to a packet has been altered. Also, files on /etc are installed by packages but are meant to be altered. But there is really no need to tamper with other packages do something nasty.

For example a package could install a service, the configuration step would configure that script to run at boot time, with root privileges. There is absolutely no need to modify existing binaries, except maybe that it could be a bit more obvious to spot.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.