Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220310234632.16194-1-casey@schaufler-ca.com>
 <20220310234632.16194-28-casey@schaufler-ca.com> <CAHC9VhQWv+04hETu3keU7Ev2nLn5MARW2R_p5hKVp3OfhD185A@mail.gmail.com>
 <987800d2-797c-e780-60f5-0e499081572f@schaufler-ca.com>
In-Reply-To: <987800d2-797c-e780-60f5-0e499081572f@schaufler-ca.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Tue, 15 Mar 2022 21:08:24 -0400
Message-ID: <CAHC9VhSYYy2_cTqZuDrVdoCboMeaUPy0a-1ArRpAhiMYr58r3g@mail.gmail.com>
Subject: Re: [PATCH v33 27/29] Audit: Add record for multiple object security contexts
To:     Casey Schaufler <casey@schaufler-ca.com>
Cc:     casey.schaufler@intel.com, jmorris@namei.org,
        linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
        linux-audit@redhat.com, keescook@chromium.org,
        john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp,
        stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Mar 15, 2022 at 8:23 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 3/15/2022 4:47 PM, Paul Moore wrote:
> > On Thu, Mar 10, 2022 at 7:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> Create a new audit record AUDIT_MAC_OBJ_CONTEXTS.
> >> An example of the MAC_OBJ_CONTEXTS (1421) record is:
> >>
> >>      type=MAC_OBJ_CONTEXTS[1421]
> >>      msg=audit(1601152467.009:1050):
> >>      obj_selinux=unconfined_u:object_r:user_home_t:s0
> >>
> >> When an audit event includes a AUDIT_MAC_OBJ_CONTEXTS record
> >> the "obj=" field in other records in the event will be "obj=?".
> >> An AUDIT_MAC_OBJ_CONTEXTS record is supplied when the system has
> >> multiple security modules that may make access decisions based
> >> on an object security context.
> >>
> >> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> >> ---
> >>   include/linux/audit.h      |  5 +++
> >>   include/uapi/linux/audit.h |  1 +
> >>   kernel/audit.c             | 47 +++++++++++++++++++++++
> >>   kernel/auditsc.c           | 79 ++++++++++++--------------------------
> >>   4 files changed, 77 insertions(+), 55 deletions(-)

...

> >> @@ -1373,18 +1362,10 @@ static void show_special(struct audit_context *context, int *call_panic)
> >>                                   from_kgid(&init_user_ns, context->ipc.gid),
> >>                                   context->ipc.mode);
> >>                  if (osid) {
> >> -                       struct lsmcontext lsmcxt;
> >>                          struct lsmblob blob;
> >>
> >>                          lsmblob_init(&blob, osid);
> >> -                       if (security_secid_to_secctx(&blob, &lsmcxt,
> >> -                                                    LSMBLOB_FIRST)) {
> >> -                               audit_log_format(ab, " osid=%u", osid);
> >> -                               *call_panic = 1;
> >> -                       } else {
> >> -                               audit_log_format(ab, " obj=%s", lsmcxt.context);
> >> -                               security_release_secctx(&lsmcxt);
> >> -                       }
> >> +                       audit_log_object_context(ab, &blob);
> > While we lose the "osid=X" in case of failure, the secid/SID is a
> > private kernel value meaning it was always of questionable value.
>
> I could come up with a change to audit_log_object_context() that
> would put out an osid= in the single security module case. I would
> prefer not to if that would be acceptable.

What I think you have right now is fine.  I thought others might point
out the field differences so I was trying to say that the existing
code really isn't very useful in case of error, there is no practical
way for someone in userspace to do anything meaningful with an
osid/secid/SID value as they are transient kernel-private values.

My apologies for the confusion.

-- 
paul-moore.com