[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez0wQ3LFxZ2jWj1sTZngTg4fEmx1=dXYuRbMMFk5CiYVbg@mail.gmail.com>
Date: Wed, 1 Nov 2023 17:23:12 +0100
From: Jann Horn <jannh@...gle.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: Stefan Bavendiek <stefan.bavendiek@...lbox.org>, "Serge E. Hallyn" <serge@...lyn.com>,
kernel-hardening@...ts.openwall.com, linux-hardening@...r.kernel.org
Subject: Re: Isolating abstract sockets
On Wed, Nov 1, 2023 at 11:57 AM Mickaël Salaün <mic@...ikod.net> wrote:
> 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. ;)
(Related, it might be nice if Landlock had a way to completely deny
access to abstract unix sockets, and a way to restrict filesystem unix
sockets with filesystem rules... LANDLOCK_ACCESS_FS_MAKE_SOCK exists
for restricting bind(), but I don't think there's an analogous
permission for connect().
Currently, when you try to sandbox an application with Landlock, you
have to use seccomp to completely block access to unix domain sockets,
or alternatively use something like the seccomp_unotify feature to
interactively filter connect() calls.
On the other hand, maybe such a feature would be a bit superfluous
when we have seccomp_unotify already... idk.)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
