mirror of https://github.com/mkerrisk/man-pages
seccomp_unotify.2: EXAMPLE: ensure path read() by the supervisor is null-terminated
From a conversation with Jann Horn: >> We should probably make sure here that the value we read is actually >> NUL-terminated? > > So, I was curious about that point also. But, (why) are we not > guaranteed that it will be NUL-terminated? Because it's random memory filled by another process, which we don't necessarily trust. While seccomp notifiers aren't usable for applying *extra* security restrictions, the supervisor will still often be more privileged than the supervised process. Reported-by: Jann Horn <jannh@google.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
e4db7ae69d
commit
bf892a6527
|
@ -1245,6 +1245,17 @@ getTargetPathname(struct seccomp_notif *req, int notifyFd,
|
|||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
/* We have no guarantees about what was in the memory of the target
|
||||
process. Therefore, we ensure that \(aqpath\(aq is null\-terminated.
|
||||
Such precautions are particularly important in cases where (as is
|
||||
common) the surpervisor is running at a higher privilege level
|
||||
than the target. */
|
||||
|
||||
int zeroIdx = len \- 1;
|
||||
if (s < zeroIdx)
|
||||
zeroIdx = s;
|
||||
path[zeroIdx] = \(aq\0\(aq;
|
||||
|
||||
if (close(procMemFd) == \-1)
|
||||
errExit("close\-/proc/PID/mem");
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue