lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZUFmW8DrxrhOhuVs@mailbox.org> Date: Tue, 31 Oct 2023 21:40:59 +0100 From: Stefan Bavendiek <stefan.bavendiek@...lbox.org> To: "Serge E. Hallyn" <serge@...lyn.com> Cc: kernel-hardening@...ts.openwall.com, linux-hardening@...r.kernel.org Subject: Re: Isolating abstract sockets 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) - Stefan
Powered by blists - more mailing lists