Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?

[Lev Olshvang]

10.11.2017, 19:24, "valdis.kletnieks at vt.edu" <valdis.kletnieks at vt.edu>:
> 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.