linux-kernel - Re: [PATCH v33 27/29] Audit: Add record for multiple object security contexts

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHC9VhSYYy2_cTqZuDrVdoCboMeaUPy0a-1ArRpAhiMYr58r3g@mail.gmail.com>
Date:   Tue, 15 Mar 2022 21:08:24 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     casey.schaufler@...el.com, jmorris@...ei.org,
        linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
        linux-audit@...hat.com, keescook@...omium.org,
        john.johansen@...onical.com, penguin-kernel@...ove.sakura.ne.jp,
        stephen.smalley.work@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v33 27/29] Audit: Add record for multiple object security contexts

On Tue, Mar 15, 2022 at 8:23 PM Casey Schaufler <casey@...aufler-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@...aufler-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@...aufler-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