如何禁止其他 Linux Kernel 模块访问某些常规文件？

Question

The problem is to prohibit access to some files (files from my "blacklist"). It implies that nobody besides me (my own kernel module) can either read or modify these files.

I've already asked this question here, on StackOverflow, but I haven't gotten an answer. There was only one solution offered to change file's permissions and file's owner. However, it isn't enough for my goals, since file's permissions as well as file's owner can be easily modified by someone else.

But I haven't given up, I've carried on studying this problem.

I replaced some fields of the system calls table by the pointers to my own functions. Thus I managed to prohibit any USER module to get an access to the files from my blacklist; in addition, this approach doesn't depend on file's permissions or file's owner. However, the key word is "user modules". I mean that any kernel module still can easily get an access to the files from my blacklist via calling, for instance, the filp_open() function. I looked through the Linux code sources and it turned out that all these system calls that I hooked ( open , openat , ...) are simple wrappers and no more.

Could you help me? Is there a way to do something with filp_open that is similar to what I've done with system calls? Any other solutions (without hooking) are welcome.

Answer 1

What you are asking for is impossible. Theoretically , this could be achieved by running the kernel under a custom-made hypervisor or running on custom-made hardware, but it would be extremely complicated (if not impossible) to achieve in reality.

You cannot protect the kernel from itself. In any normal scenario (ie no dedicated hardware or hypervisor), the Linux kernel runs at the highest privilege level on the machine, and can therefore revert any changes you make if it wants. If your module needs to deny access to some file to the whole kernel , then there's really something conceptually wrong about what you are doing. Moreover, you seem to be assuming that other kernel modules would be somehow "interested" in messing with your module: why would that be the case?

Furthermore, even changing permissions or overriding syscalls does not solve any problem: unless you correctly configure kernel lockdown (kernel >= v5.4) and/or some other security measure like module signing (and ideally also secure boot), the root user is always able to insert modules and subvert your "security" measures.

If you need to deprive root of access to these files, then as I said there's really something logically wrong. The root user can already do whatever it wants with whichever configuration file it wants, of course destroying important configuration files is going to break the system, but that's not really something that you can avoid. Assuming that root is evil doesn't make much sense as a threat model in any normal scenario.