On Fri, 10 Nov 2017 16:30:17 +0300, Lev Olshvang said: > But the attempt to replace shared object library succeeded, and I do not > understand the logic of this decision You might want to do an lsof after such an upgrade, and ponder what *really* happened. Hint 1: How do you do this in a way that doesn't break currently running binaries? Hint 2: Do you see the string '(deleted)' in the lsof output? What does it mean? > I want to patch my kernel to forbid shared objects live replacement. ( as I > said I worry about security issue) Attackers doing that is the least of your problems. If your system is correctly set up, if an attacker manages to get to a point where this attack is feasible, you're *already* in deep trouble even before they do a live replacement. For bonus points - you're probably worrying about the wrong security issue, because you're probably only thinking about the *obvious* problem. The trouble is that even if you forbid live replacement of a .so, that's *not* the only attack surface. Phrack ran an interesting article many years ago on how to inject a module into a Linux kernel *even if the kernel was built with CONFIG_MODULE=n*. http://phrack.org/issues/58/7.html#article (The important part isn't the exact mechanism - that SucKIT code from 16 years ago probably won't work on a 4.14 kernel. But it illustrates the out-of-box thinking the attacker can use - and that you'll have to defend against. How did Emacs in times gone by do an 'unexec()' to write out an executable image of itself, as the state was after startup? What can you over-write by setting /proc/sys/kernel/core_pattern, forking, and then forcing a coredump in the child process? Can you combine the techniques to splat a .so that's currently in use?
Attachment:
pgprc6sU80Da4.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
