Thread (55 messages) 55 messages, 8 authors, 2018-04-11

Re: [PATCH bpf-next v8 08/11] landlock: Add ptrace restrictions

From: Mickaël Salaün <mic@digikod.net>
Date: 2018-03-06 22:29:29
Also in: lkml, netdev

On 28/02/2018 01:09, Andy Lutomirski wrote:
On Wed, Feb 28, 2018 at 12:00 AM, Mickaël Salaün [off-list ref] wrote:
quoted
On 28/02/2018 00:23, Andy Lutomirski wrote:
quoted
On Tue, Feb 27, 2018 at 11:02 PM, Andy Lutomirski [off-list ref] wrote:
quoted
On Tue, Feb 27, 2018 at 10:14 PM, Mickaël Salaün [off-list ref] wrote:
quoted
I think you're wrong here.  Any sane container trying to use Landlock
like this would also create a PID namespace.  Problem solved.  I still
think you should drop this patch.
Containers is one use case, another is build-in sandboxing (e.g. for web
browser…) and another one is for sandbox managers (e.g. Firejail,
Bubblewrap, Flatpack…). In some of these use cases, especially from a
developer point of view, you may want/need to debug your applications
(without requiring to be root). For nested Landlock access-controls
(e.g. container + user session + web browser), it may not be allowed to
create a PID namespace, but you still want to have a meaningful
access-control.
The consideration should be exactly the same as for normal seccomp.
If I'm in a container (using PID namespaces + seccomp) and a run a web
browser, I can debug the browser.

If there's a real use case for adding this type of automatic ptrace
protection, then by all means, let's add it as a general seccomp
feature.
Right, it makes sense to add this feature to seccomp filters as well.
What do you think Kees?

Attachments

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