Thread (66 messages) 66 messages, 6 authors, 2016-10-05

Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing

From: Kees Cook <hidden>
Date: 2016-10-03 22:57:02
Also in: lkml, netdev

On Tue, Sep 20, 2016 at 10:08 AM, Mickaël Salaün [off-list ref] wrote:
On 15/09/2016 11:19, Pavel Machek wrote:
quoted
Hi!
quoted
This series is a proof of concept to fill some missing part of seccomp as the
ability to check syscall argument pointers or creating more dynamic security
policies. The goal of this new stackable Linux Security Module (LSM) called
Landlock is to allow any process, including unprivileged ones, to create
powerful security sandboxes comparable to the Seatbelt/XNU Sandbox or the
OpenBSD Pledge. This kind of sandbox help to mitigate the security impact of
bugs or unexpected/malicious behaviors in userland applications.

The first RFC [1] was focused on extending seccomp while staying at the syscall
level. This brought a working PoC but with some (mitigated) ToCToU race
conditions due to the seccomp ptrace hole (now fixed) and the non-atomic
syscall argument evaluation (hence the LSM hooks).
Long and nice description follows. Should it go to Documentation/
somewhere?

Because some documentation would be useful...
                                                              Pavel
Right, but I was looking for feedback before investing in documentation. :)
Heh, understood. There are a number of grammar issues that slow me
down when reading this, so when it does move into Documentation/, I'll
have some English nit-picks. :)

While reading I found myself wanting an explicit list of "guiding
principles" for anyone implementing new hooks. It is touched on in
several places (don't expose things, don't allow for privilege
changes, etc). Having that spelled out somewhere would be nice.

-Kees

-- 
Kees Cook
Nexus Security
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help