From af147ed260551d76ac3d56552f1a60be65b62024 Mon Sep 17 00:00:00 2001 From: Florian Obser Date: Sun, 19 Feb 2023 11:50:17 +0100 Subject: [PATCH] Explain unveil a bit more; requested by otto. --- privsep.org | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/privsep.org b/privsep.org index 8151163..e72cd8e 100644 --- a/privsep.org +++ b/privsep.org @@ -541,6 +541,16 @@ can cause if they ever get all the way to the /parent/ process using fatal("unveil"); #+end_src +With unveil(2) a process can restrict its view of the file-system. The +first call to unveil(2) removes access to the entire file-system from +the process, except for the first argument of unveil(2). The second +argument specifies the permission the program requests for the path: +"=r=" means read, "=w=" write and "=c=" create. Subsequent calls +unveil more parts of the file-system. Since we cannot use pledge(2) in +the /parent/ process, we need to somehow lock-in the list of unveiled +paths so that an attacker cannot simply add more. ~unveil(NULL, +NULL);~ does that, any subsequent calls to unveil(2) will fail. + It turns out that the parent process needs very little access to the file system. It needs access to the dhcpleased(8) config file, the bpf(4) device and the directory where lease files are stored. That