Explain unveil a bit more; requested by otto.
This commit is contained in:
parent
087094cf06
commit
af147ed260
10
privsep.org
10
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
|
||||
|
Loading…
Reference in New Issue
Block a user