kernel hook doubt

fluca1978

fluca1978

Hi all,

I was reading an example of how to hook the kernel data structures to hide a process, in particular removing its descriptor from the kernel process lists. A doubt I've got is if removing the process descriptor from the kernel structures does not make the process really disappear from the system, that is no more scheduled for running. In fact, when another process relinquishes the CPU and the phantom one has to run, how can the scheduler select such a process if no references to it exist?
 
Could the trick be around the distinction between processes and threads? I mean the choosethread used to get the next thread to schedule for running is working on a thread structure, not a process one, so the queues are different for threads and processes. Any advice?
 
Like you have noticed scheduler is switching between threads and not processes so all it needs to know is included in thread table.
 
Thanks, and here come other doubts: if the kernel is switching and needing only thread information, what is (today) the purpose of the proc structure? I mean, all the information for the proc structure could be retrieved starting from the thread one, and therefore why does the kernel organizes the proc structures in lists? Does it make more sense to use only thread lists? This approach would make also much more difficult to hide a running process as described in the book.
 
the following piece of code, given a running thread, should provide the current process associated to it:

Code: 
struct thread *td;                                                                 
struct proc *p;                                                                    
....                                                                                           
td = curthread;                                                                    
p = td->td_proc;

However the point is, where are thread handled? I mean, ok, having the process to disappear from the process list causes the process to disappear from the system, but when are threads handled so that the thread can still be scheduled? Moreover, isn't it possible from userland to see running threads (even if no proc is in the allproc)?
 
I believe I got it, but comments are required.
The struct thread references the struct proc which belong to, so that given a thread it is always possible to get the proc. The scheduler works on threads, so it does not "see" processes, but from threads it is possible to get processes. The allproc list keeps track of all processes and therefore all threads. When a process is removed by the allproc list the system becomes unaware of such process, but other processes can still see it due to p_list field of the struct proc, and therefore the scheduler continues to cycle among all existing processes thanks to the inter-process links.
If this is right, then the question becomes what is the aim of the allproc list? I mean, the list could become an inter-process list rooted at init, right? Moreover, if the above is true, it means that hiding a process is just a "baby" step of a rootkit, since there is no way to hide a thread, right?
 
You cannot hide a thread as far as I know as hiding a thread from the system causes it to not execute. The allproc list is transversed once per second to gather statistics on all the processes in the system. Furthermore, struct thread and struct proc actually reference each other, so if you have one, you can get the other. The p_list field I think is a pointer to the head of the list, not the actual list itself. So if one removed the proc entry from the allproc list, then the other processes would not be able to see the removed process. As to what the list is used for, as I stated above, the list is transversed for statistics and it is provided to utilities such as top and ps.
 
You must log in or register to reply here.
Back
Top