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:
Michael Kerrisk 2020-10-16 11:02:08 +02:00
parent e4db7ae69d
commit bf892a6527
1 changed files with 11 additions and 0 deletions

View File

@ -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");
}