Re: [PATCH v2 1/5] lsm: Add hook unix_path_connect

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2400 bytes --]

On 1/15/26 05:10, Günther Noack wrote:
> On Tue, Jan 13, 2026 at 06:27:15PM -0500, Paul Moore wrote:
>> On Tue, Jan 13, 2026 at 4:34 AM Christian Brauner <brauner@kernel.org> wrote:
>>> On Sat, Jan 10, 2026 at 03:32:57PM +0100, Günther Noack wrote:
>>>> From: Justin Suess <utilityemal77@gmail.com>
>>>>
>>>> Adds an LSM hook unix_path_connect.
>>>>
>>>> This hook is called to check the path of a named unix socket before a
>>>> connection is initiated.
>>>>
>>>> Cc: Günther Noack <gnoack3000@gmail.com>
>>>> Signed-off-by: Justin Suess <utilityemal77@gmail.com>
>>>> ---
>>>>  include/linux/lsm_hook_defs.h |  4 ++++
>>>>  include/linux/security.h      | 11 +++++++++++
>>>>  net/unix/af_unix.c            |  9 +++++++++
>>>>  security/security.c           | 20 ++++++++++++++++++++
>>>>  4 files changed, 44 insertions(+)
>>
>> ...

...

> * Some properties of the resolved socket are still observable to
>   userspace:
> 
>   When we only pass the path to a later LSM hook, there are a variety
>   of additional error case checks in af_unix.c which are based on the
>   "other" socket which we looked up through the path.  Examples:
> 
>   * was other shutdown(2)? (ECONNREFUSED on connect or EPIPE on dgram_sendmsg)
>   * does other support SO_PASSRIGHTS (fd passing)? (EPERM on dgram_sendmsg)
>   * would sendmsg pass sk_filter() (on dgram_sendmsg)
> 
>   For a LSM policy that is supposed to restrict the resolution of a
>   UNIX socket by path, I would not expect such properties of the
>   resolved socket to be observable?
> 
>   (And we also can't fix this up in the LSM by returning a matching
>   error code, because at least unix_dgram_sendmsg() returns multiple
>   different error codes in these error cases.)
> 
>   I would prefer if the correctness of our LSM did not depend on
>   keeping track of the error scenarios in af_unix.c.  This seems
>   brittle.

Indeed so.

> Overall, I am not convinced that using pre-existing hooks is the right
> way and I would prefer the approach where we have a more dedicated LSM
> hook for the path lookup.
> 
> Does that seem reasonable?  Let me know what you think.
> 
> –Günther

Having a dedicated LSM hook for all path lookups is definitely my
preferred approach.  Could this allow limiting directory traversal
as well?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]