Cyrill Gorcunov <gorcunov@xxxxxxxxx> writes:
On Tue, Jul 12, 2016 at 07:30:29PM +0400, Stanislav Kinsburskiy wrote:I believe the original concern was someone injecting a code into a
This limitation came with the reason to remove "anotherPersistent exe-link doesn't guarantee anything if you have rights to ptrace
way for malicious code to obscure a compromised program and
masquerade as a benign process" by allowing "security-concious program can use
this prctl once during its early initialization to ensure the prctl cannot
later be abused for this purpose":
But the way how the feature can be used is the following:
1) Attach to process via ptrace (protected by CAP_SYS_PTRACE)
2) Unmap all the process file mappings, related to "exe" file.
3) Change exe link (protected by CAP_SYS_RESOURCE).
IOW, some other process already has an access to process internals (and thus
it's already compromised), and can inject fork and use the child of the
compromised program to masquerade.
Which means this limitation doesn't solve the problem it was aimed to.
While removing this limitation allow to replace files from underneath of a
running process as many times as required. One of the use cases is network
file systems migration (NFS, to be precise) by CRIU.
NFS mount can't be mounted on restore stage because network is locked.
To overcome this limitation, another file system (FUSE-based) is used. Then
opened files replaced by the proper ones NFS is remounted.
Thus exe link replace has to be done twice: first on restore stage and second
- when actual NFS was remounted.
Signed-off-by: Stanislav Kinsburskiy <skinsbursky@xxxxxxxxxxxxx>
task and inject own code into (from security POV). So lets rip it out.
Acked-by: Cyrill Gorcunov <gorcunov@xxxxxxxxxx>
process and playing silly buggers with the exe link. Someone who does
not have ptrace capability.
It is completely not ok to change this until someone goes back to the
original conversation and looks at the original threat model, and