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

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

[Lev Olshvang]

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/9672512#9672512

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.

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

[Greg KH]

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/9672512#9672512
> 
> 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

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

[valdis.kletnieks at vt.edu]

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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170307/2a311450/attachment.bin 

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

[Lev Olshvang]

An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170308/fa16af86/attachment.html 

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

[Greg KH]

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

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

[valdis.kletnieks at vt.edu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170308/b64078e1/attachment.bin