We should write up a threat model for Landlock,
to explain what is and what is not a security bug.
This will help security researchers and maintainers alike in reducing duplicate work
for cases where the problem is already known or where the problem is not considered a security bug.
Similar to the Linux threat model, which was added to documentation in May:
In some cases, the boundary between "vulnerability" and "new feature request" is blurry (e.g. we had to discuss it for whiteout objects), for these it might also be relevant to document even when we decided in discussion to treat it as feature request.
Some previously reported ones
Often reported non-vulnerabilities
- Operations done through an
io_uring are done with the credentials of the process at the time when the io_uring was created. This is working as intended implemented, but not mentioned loudly enough in documentation.
We should write up a threat model for Landlock,
to explain what is and what is not a security bug.
This will help security researchers and maintainers alike in reducing duplicate work
for cases where the problem is already known or where the problem is not considered a security bug.
Similar to the Linux threat model, which was added to documentation in May:
In some cases, the boundary between "vulnerability" and "new feature request" is blurry (e.g. we had to discuss it for whiteout objects), for these it might also be relevant to document even when we decided in discussion to treat it as feature request.
Some previously reported ones
LANDLOCK_ACCESS_NET_CONNECT_TCP: TCP fast-open: Restrict TCP Fast Open connection #41LANDLOCK_ACCESS_NET_BIND_TCP: Multipath TCP bind() does not get restricted: Restrict Multipath TCP #54Often reported non-vulnerabilities
io_uringare done with the credentials of the process at the time when theio_uringwas created. This is working asintendedimplemented, but not mentioned loudly enough in documentation.