Talk:OSC:Stealth Processes & PCBs
From SOFTICE
Contents |
Migration to SOFTICE-OS-LABS virtual appliance
These are the modifications necessary to port this lab to the SOFTICE-OS-LABS vmware image. Alessio 07:15, 13 July 2008 (EDT)
[solved] Exploring the struct task_struct
This one is working ok on the newer kernel
[solved] Missing link: Hiding a process
Second [solved] exercise doesn't compile anymore in so far that the macro REMOVE_LINKS and SET_LINKS which was defined in /usr/src/linux/include/linux/sched.h in kernel 2.6.16.20 is no longer defined in 2.6.24.3. Here is the definition as of 2.6.16.20. For now, let's add it to the LKM source;
#define REMOVE_LINKS(p) do { \
if (thread_group_leader(p)) \
list_del_init(&(p)->tasks); \
remove_parent(p); \
} while (0)
#define SET_LINKS(p) do { \
if (thread_group_leader(p)) \
list_add_tail(&(p)->tasks,&init_task.tasks); \
add_parent(p, (p)->parent); \
} while (0)
We have actually to modify slightly SET_LINKS so that the macro add_parent takes only one parameter. This is how it was defined in 2.6.16.20
#define add_parent(p, parent) list_add_tail(&(p)->sibling,&(parent)->children)
and this is how it is defined now in 2.6.24.3
#define add_parent(p) list_add_tail(&(p)->sibling,&(p)->parent->children)
So we use it as follows in the above definition of SET_LINKS
#define SET_LINKS(p) do { \
if (thread_group_leader(p)) \
list_add_tail(&(p)->tasks,&init_task.tasks); \
add_parent(p); \
} while (0)
Issues faced when writing modules
module: spy on process when opening file named "whoami"
- Much of the code is already out there (I copied 90% of it from the LKMPG---and yes, the copyright statement is still there).
- No libc... but students can use the strcmp() in kernel: <linux/string.h>. Same semantics as libc strcmp().
- Need to use getname() (in <linux/fs.h>) to copy filename from user space to kernel space. User data is off limits to kernel modules except through accessor functions (copy_from_user(), copy_to_user(), getname(), etc).
- Students may need knowledge of module_param().
LKMs vs. direct kernel hacking
What's stopping us from having the students edit the kernel directly? Each student could simply have their own UML instance that they can edit as they see fit. That way, instead of just hijacking existing syscalls, they could implement entirely new ones (Linux Kernel Development 2e has an example of how this is done...) It also neatly sidesteps the issue of exporting sys_call_table. --BenjaminGeiger
Alessio:
Let's start by introducing students to the kernel by leveraging the modularity of LKMs. Benefits?
- we help building kernel development reflexes, it's like learning to program in kernel space and using kernel data structures and functions vs. learning to modify a huge piece of existing code
- we uncover the kernel source progressively instead of throwing students in it for the first session
- we encourage students to keep writing code from scratch, instead of making "surgical strikes" in a huge code base.
The most recent publications (june 2006) should address these points in much more details. The paper accepted to CCSC-SE 2006 should be the clearer on the topic and the presentations at ITiCSE and EISTA should also address this (very fundamental) question: why bother with LKMs while most labs on the net have students modify the kernel source code itself directly. Also, while it looks cleaner to not hijack system calls (we underline the problems related to that, as do the classic texts on LKM programming), it's also bad practice to add system calls to the kernel API whithout it being the last possibility. This first lab is more of an excuse to start diggin into the kernel really :)
BenjaminGeiger: Agreed... though, after one example of syscall hacking, we may want to start showing them the cleaner way to do it (sysfs/procfs)...
task_struct on 2.6.12.4
It's a gigantic struct. No wonder they slab it and use thread_info at the end of each thread's kernel stack.
I seriously doubt we're going to need to teach all of this... should we go through this and isolate the relevant members? How much of this is actually needed to implement process hiding?
Alessio: yup, that's too huge for this lab and, also, explaining it fully would mean detailing memory management and file systems. That might be indeed quite overwhelming depending of the lectures' order.
The code, copied verbatim from /usr/src/linux-2.6.12.4/include/linux/sched.h on softice:
<snip>
Alessio: just moved this to the main page to comment it through the briefing section.
/dev/kmem section removed from main page and put here
- not sure what kind of info we could add here, maybe a memory map of the kernel as opposed to the virtual memory map of any process and their overlap
- can we work on a user land program to search through /dev/kmem for something or do we need to write this from the kernel itself (LKM)
- we could look for the pattern of code featured by a LKM in one of its constants so that we identify its stack for instance. If we can write we can even substitute a return value on the stack w/ the address of some code in another LKM (we're getting closer to the hot patching technique for syscall interception here)
BenjaminGeiger: I don't understand what this is about. We don't need to use /dev/kmem to hide processes; it's just another system call. (In this case, it's getdents(), as the version of ps used in 99% of Linux distributions looks at /proc to find processes. Perhaps we should put the "hide files and directories" lab before this one?)
alessio: moving the hide files / dirs ahead makes sense. This section is out of place; the idea is to give a map of kernel memory to students and compare it to a map of the memory as seen from inside a user-land process. The /dev/kmem idea started to hang around these pages as an application of that knowledge to hot patch memory. We're getting far from the process hiding indeed...
