how to get filename of execve() system call from kernel module which install hook to syscall table to intercept original syscall in kernels before 4.2 and atter 4.2 ? X86_64
Hello all, In kernels 3.X up to 4.2 execve(|) system call was for x86_64 architecture the the system call was made through some magic ( I can't say I understand it ) assembly stub in arch/x86/kernel/entry_64.S so up to kernel 4.2 it was possble to patch this assembly to install the hook, ex. see http://stackoverflow.com/questions/8372912/hooking-sys-execve-on-linux-3-x/9... But this hook still can't access in a proper way filename argument, althouth I tried to do it with in the same way as fs/exec.c does : using kernel's getname() function (which I was need to find through kallsyms_lookup_name() In kernels 4.2 and up, the arch/x86/kernel/entry_64.S is gone, and I still dont' have a clue what to do to get filename as a char string. Please advise. Lev.
On Mon, Mar 06, 2017 at 10:18:26AM +0300, Lev Olshvang wrote:
Hello all,
In kernels 3.X up to 4.2 execve(|) system call was for x86_64 architecture the the system call was made through some magic ( I can't say I understand it ) assembly stub in arch/x86/kernel/entry_64.S so up to kernel 4.2 it was possble to patch this assembly to install the hook, ex. see http://stackoverflow.com/questions/8372912/hooking-sys-execve-on-linux-3-x/9...
But this hook still can't access in a proper way filename argument, althouth I tried to do it with in the same way as fs/exec.c does : using kernel's getname() function (which I was need to find through kallsyms_lookup_name()
In kernels 4.2 and up, the arch/x86/kernel/entry_64.S is gone, and I still dont' have a clue what to do to get filename as a char string.
Why do you want to hook a syscall? that's a very complex, and broken, and ill-advised thing to do. Please don't do that. What problem are you trying to solve here that led you to think that putting a syscall hook in is a good solution? thanks, greg k-h
On Tue, 07 Mar 2017 20:22:33 +0100, Greg KH said:
On Mon, Mar 06, 2017 at 10:18:26AM +0300, Lev Olshvang wrote:
Why do you want to hook a syscall? that's a very complex, and broken, and ill-advised thing to do. Please don't do that.
What problem are you trying to solve here that led you to think that putting a syscall hook in is a good solution?
To expand on that - most cases where you want to hook execve() to get the filename should *already* be doable via the LSM (Linux Security Module) interface. If you're just doing a chainsaw patch that won't be distributed, a good starting point is to just add to security/yama/yama_lsm.c (all that does currently is mediate calls to ptrace()). If you're trying to build an entirely new LSM, the Yama code is a good framework to copy...
On Wed, Mar 08, 2017 at 03:20:57PM +0300, Lev Olshvang wrote:
Hi Greg, Thank you for a prompt reply. My intention is to build some euristics for Intrusion detection of embedded based on sequence of syscalls. I am collecting syscall events and send then with netlink to my monitor. Since platform may use SELinux or other LSM, I thought the hook of syscall is the only point I can use to catch syscalls. Is it wrong direction ?
Yes it is, please use the audit subsystem for something like that, it is exactly what it was designed and built for. You can do everything you want to from userspace.
I was googling and reading kernel git logs trying find out the why execve, clone, fork use assembly glue code instead of calling sys_execve like others syscalls. Can you give me some point where to look?
Nope, don't mess with that :) good luck! greg k-h
On Wed, 08 Mar 2017 15:20:57 +0300, Lev Olshvang said:
Hi Greg, Thank you for a prompt reply. My intention is to build some euristics for Intrusion detection of embedded based on sequence of syscalls. I am collecting syscall events and send then with netlink to my monitor. Since platform may use SELinux or other LSM, I thought the hook of syscall is the only point I can use to catch syscalls. Is it wrong direction ?
SELinux supports being stacked with a "small" LSM that can do what you want. Or use the already-provided audit function to track syscalls and send them to userspace via netlink to your monitor.
participants (3)
-
Greg KH -
Lev Olshvang -
valdis.kletnieks＠vt.edu