在netfilter挂钩中查找可执行文件发送数据包的名称 [英] Finding name of executable sending packet in a netfilter hook

问题描述

我正在编写一个内核模块，该模块使用netfilter挂钩过滤TCP数据包，并且需要找出发送数据包的可执行文件的路径.到目前为止，我已经使用了以下方法，但是它显示的名称似乎与所使用的可执行文件无关(/usr/lib/firefox/firefox ， usr/bin/telnet.netkit >和/usr/bin/wget ).

I'm writing a kernel module that uses a netfilter hook to filter TCP packets and need to find out the path to the executable that is sending the packets. So far I have used the following approach but it prints names that are seemingly unrelated to the executables used (/usr/lib/firefox/firefox, usr/bin/telnet.netkit and /usr/bin/wget).

pid_t pid = current->pid;
struct path path;
char buff[BUFF_LEN];
snprintf (buff, BUFF_LEN, "/proc/%d/exe", pid);
if(!kern_path(buff, LOOKUP_FOLLOW, &path)) {
    struct dentry* procEntry = path.dentry;
    printk("Process: %s\n", procEntry->d_name.name);
    printk("Parent: %s\n", procEntry->d_parent->d_name.name);
}

内核日志输出:

推荐答案

这听起来像是大学作业质量不佳，我对这里已经出现了类似的印象.

This reads like a poor quality college assignment and I have a distinct impression something of the sort already appeared here.

您的代码最有可能在中断上下文中执行，即，随机线程被中断以进行数据包处理，并且当前"是指向该随机线程的指针.这应该很容易验证，例如通过获取回溯信息-可以与WARN_ONCE等类似.

Your code most likely executes from an interrupt context, i.e. a random thread got interrupted to do packet processing and 'current' is a pointer to said random thread. This should be easy to verify e.g. by obtaining a backtrace -- doable with WARN_ONCE and the like.

通过procfs查找current的可执行文件名称很奇怪. procfs必须做更多的工作，最终还是要访问有效的最新内容.更糟糕的是，您无法放置找到的路径，从而浪费了资源.如果此代码确实是从中断处理程序执行的，则结果不仅是荒谬的，而且由于潜在的睡眠而无法安全地使用此方法获得.

Looking for executable name of current by going through procfs is weirdly bad. procfs has to do more work and ends up accessing what's effectively current anyway. To make matters worse, you fail to put the found path thus you leak resources. If this code indeed executes from an interrupt handler, the result is not only nonsensical but can't be safely obtained with this method due to sleep potential.

即使您要获取正确的"可执行文件名称，整个任务也很糟糕.一个进程可以通过多种方式来改变另一个进程的执行.因此有效地绕过了您使用的任何过滤器.有趣的是，有一种方法可以将您的进程名称更改为其他名称而无需执行任何操作，从而使该概念无效.

Even if you were to obtain the "right" executable name, the entire assignment is crap. There are many ways in which one process can alter execution of another. thus effectively bypassing whatever filter you have in place. Interestingly there is a way to just change your process name to something else without execing anything, once more invalidating the concept.

您能做的最好的事情是按凭据过滤，但是它们不是特定于进程的.原则上，您可以将selinux标签添加到文件中并以此进行过滤，但这又很薄弱.

The best you can do is filter by credentials, but they are not process-specific. In principle you can add selinux labels to files and filter by that, but once more that's weak.

简而言之，这是胡说八道.

In short, the assignment is bullshit.

这篇关于在netfilter挂钩中查找可执行文件发送数据包的名称的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！