kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: "Mickaël Salaün" <mic@digikod.net>
To: Stefan Bavendiek <stefan.bavendiek@mailbox.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	 kernel-hardening@lists.openwall.com,
	linux-hardening@vger.kernel.org
Subject: Re: Isolating abstract sockets
Date: Wed, 1 Nov 2023 11:56:38 +0100	[thread overview]
Message-ID: <20231101.eeshae5Ahpei@digikod.net> (raw)
In-Reply-To: <ZUFmW8DrxrhOhuVs@mailbox.org>

On Tue, Oct 31, 2023 at 09:40:59PM +0100, Stefan Bavendiek wrote:
> On Tue, Oct 24, 2023 at 11:07:14AM -0500, Serge E. Hallyn wrote:
> > In 2005, before namespaces were upstreamed, I posted the 'bsdjail' LSM,
> > which briefly made it into the -mm kernel, but was eventually rejected as
> > being an abuse of the LSM interface for OS level virtualization :)
> > 
> > It's not 100% clear to me whether Stefan only wants isolation, or
> > wants something closer to virtualization.
> > 
> > Stefan, would an LSM allowing you to isolate certain processes from
> > some abstract unix socket paths (or by label, whatever0 suffice for you?
> >
> 
> My intention was to find a clean way to isolate abstract sockets in network
> applications without adding dependencies like LSMs. However the entire approach
> of using namespaces for this is something I have mostly abandoned. LSMs like
> Apparmor and SELinux would work fine for process isolation when you can control
> the target system, but for general deployment of sandboxed processes, I found it
> to be significantly easier (and more effective) to build this into the
> application itself by using a multi process approach with seccomp (Basically how
> OpenSSH did it)

I agree that for sandbox use cases embedding such security policy into
the application itself makes sense. Landlock works the same way as
seccomp but it sandboxes applications according to the kernel semantic
(e.g. process, socket). The LSM framework is just a kernel
implementation detail. ;)

  reply	other threads:[~2023-11-01 10:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-18 19:29 Isolating abstract sockets Stefan Bavendiek
2023-10-24 13:46 ` Serge E. Hallyn
2023-10-24 14:05   ` Boris Lukashev
2023-10-24 14:15     ` Serge E. Hallyn
2023-10-24 15:55       ` Boris Lukashev
2023-10-24 16:11         ` Serge E. Hallyn
2023-10-24 14:14   ` Paul Moore
2023-10-24 14:18     ` Serge E. Hallyn
2023-10-24 14:29       ` Paul Moore
2023-10-24 16:07         ` Serge E. Hallyn
2023-10-25 11:54           ` Mickaël Salaün
2023-10-31 20:40           ` Stefan Bavendiek
2023-11-01 10:56             ` Mickaël Salaün [this message]
2023-11-01 16:23               ` Jann Horn
2023-11-02 14:50                 ` Mickaël Salaün
2023-10-25 17:10   ` Jann Horn
2023-10-25 17:22     ` Serge E. Hallyn
2023-10-25 17:41       ` Jann Horn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231101.eeshae5Ahpei@digikod.net \
    --to=mic@digikod.net \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=stefan.bavendiek@mailbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).