Why not just write a FUSE module?
Maybe because the author prefers to play with kernel. Other option is create a wrapper library and enforce it's usage with LD_PRELOAD.
Kernel module for advanced rickrolling replaces open() call
31–40 of 67 posts
Re: Kernel module for advanced rickrolling replaces open() call
#32Re: Kernel module for advanced rickrolling replaces open() call
#33Earlier quoted context omitted.
Bullshit. Anyone who's using open() can kill the kernel after loading this module.
I guess you meant, ``Anyone who's using open() can kill the kernel after somebody else loads the module.''. Which is far worse: any unprivileged user, say the victim of rickroll, can bite back hard.
This seems like a feature not a bug.
Re: Kernel module for advanced rickrolling replaces open() call
#34p = (char *)(path + strlen(path) - 4); This is a very bad idea as path is user-supplied and has to be treated as malicious. An attacker can omit the string-terminator...
BTW: write_cr0(read_cr0() | 0x10000) is a absolute no-go. It's a nice and funny kernel module but it dooms the kernel's security.
If we could take CR0 et al manipulations away from module authors, we'd do it long ago. Sigh...
Re: Kernel module for advanced rickrolling replaces open() call
#35p = (char *)(path + strlen(path) - 4); This is a very bad idea as path is user-supplied and has to be treated as malicious. An attacker can omit the string-terminator...
Out of curiosity, I checked out how the open syscall in linux works (see fs/open.c). It uses getname (from fs/namei.h), which effectively copies the filename from userland memory to a chunk of kernel memory. It uses strncpy_from_user to do this and uses PATH_MAX as the maximum length. So even the linux kernel does rely on the fact that there is a null terminator in the string. So your assumption on omitting the null…
> It uses strncpy_from_user to do this and uses PATH_MAX as the maximum length. So even the linux kernel does rely on the fact that there is a null terminator in the string.
The PATH_MAX guarantees that the string copy will terminate even if no null character is present.
Now if any routines that call strncpy_from_user assume that it leaves them with a null terminated string there is still a potential for trouble but that does not stem from the use of strncpy_from_user.
Check the implementation for do_getname:
http://lxr.free-electrons.com/source/fs/namei.c
And you'll see that it returns -ENAMETOOLONG when the name is >= the buffer allocated, only < len is allowed. (line 133 in the link above).
Re: Kernel module for advanced rickrolling replaces open() call
#36Re: Kernel module for advanced rickrolling replaces open() call
#37Re: Kernel module for advanced rickrolling replaces open() call
#38Re: Kernel module for advanced rickrolling replaces open() call
#39Earlier quoted context omitted.
BTW: write_cr0(read_cr0() | 0x10000) is a absolute no-go. It's a nice and funny kernel module but it dooms the kernel's security.
If we could take CR0 et al manipulations away from module authors, we'd do it long ago. Sigh...
This is why I avoid out-of-tree modules. At least someone had to glance over the in-tree module before I run it on my machine. When you download random kernel modules from the Internet, they're probably from people too lazy to have their code properly reviewed. And if they're too lazy to have their code reviewed, they probably don't feel too bad about disabling all page write protection, either.
Re: Kernel module for advanced rickrolling replaces open() call
#40This is great, for the fun of course, but also and mainly because it is a simple example of a working kernel module, which is not something one can see very often.
What are you talking about? The linux sources are full of simple examples of working kernel modules.
But those are all things like parallel port drivers. This is for an Internet meme!!!!