[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFqZXNuescrj3bY8FnK71f4JSXvnptvVoQhqH1eBrJ=PTYoAMQ@mail.gmail.com>
Date: Fri, 17 Feb 2023 17:18:42 +0100
From: Ondrej Mosnacek <omosnace@...hat.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kernel/sys.c: fix and improve control flow in __sys_setres[ug]id()
On Thu, Feb 16, 2023 at 5:11 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> Andrew Morton <akpm@...ux-foundation.org> writes:
>
> > On Wed, 15 Feb 2023 14:18:07 +0100 Ondrej Mosnacek <omosnace@...hat.com> wrote:
> >
> >> 1. First determine if CAP_SET[UG]ID is required and only then call
> >> ns_capable_setid(), to avoid bogus LSM (SELinux) denials.
> >
> > Can we please have more details on the selinux failures? Under what
> > circumstances? What is the end-user impact?
>
> It is puzzling the structure with having the capability check first
> dates to 2.1.104 (when a hand coded test for root was replaced
> with capable(CAP_SETID). Which means the basic structure and logic
> of the code is even older than that.
I don't find it that puzzling - either the code structure predates the
moment LSMs were plugged into capable() (and no one did an audit of
existing callers at that time) or it was written without awareness
that capable() may have side effects (which is not surprising, since
it is not documented properly).
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
Powered by blists - more mailing lists