10.11.2017, 19:24, "valdis.kletnieks@xxxxxx" <valdis.kletnieks@xxxxxx>: > 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? > > , Hi Valdis, Thank you for prompt response. I am afraid you did not quite understand my question. I am going to patch inode reference count of mapped shared libs to disable overwrite because I do not see any other solution giving requirements I got - prevent overwrite by simple tools like dd. I agree with you that is is this is not enough to protect the system, but this is just one line of defense. I understand that it is hard to not crash running executable by changing lib under the hood, but hackers can repedeately crash programs until desired result achieved. I am not seasoned kernel developer, there are a lot of things do not know about kernel. I would like to consult with list whether increment inode nlink_count in shared libraries in the same way is done for executable will break things in kernel. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
