linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: rgb@redhat.com
Cc: sgrubb@redhat.com, cgroups@vger.kernel.org,
	containers@lists.linux-foundation.org, linux-api@vger.kernel.org,
	linux-audit@redhat.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	ebiederm@xmission.com, luto@kernel.org, carlos@redhat.com,
	dhowells@redhat.com, viro@zeniv.linux.org.uk, simo@redhat.com,
	Eric Paris <eparis@parisplace.org>,
	serge@hallyn.com
Subject: Re: [RFC PATCH ghak90 (was ghak32) V3 02/10] audit: log container info of syscalls
Date: Mon, 23 Jul 2018 09:16:25 -0400	[thread overview]
Message-ID: <CAHC9VhSUhSDaXzD9fpxm-oK=U4MieekKwY-pypzT=RA1HBw6+Q@mail.gmail.com> (raw)
In-Reply-To: <20180721202930.a7rypxc5rxi3hyiv@madcap2.tricolour.ca>

On Sat, Jul 21, 2018 at 4:32 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2018-07-20 18:13, Paul Moore wrote:
> > On Wed, Jun 6, 2018 at 1:00 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > > Create a new audit record AUDIT_CONTAINER to document the audit
> > > container identifier of a process if it is present.
> > >
> > > Called from audit_log_exit(), syscalls are covered.
> > >
> > > A sample raw event:
> > > type=SYSCALL msg=audit(1519924845.499:257): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=56374e1cef30 a2=241 a3=1b6 items=2 ppid=606 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="tmpcontainerid"
> > > type=CWD msg=audit(1519924845.499:257): cwd="/root"
> > > type=PATH msg=audit(1519924845.499:257): item=0 name="/tmp/" inode=13863 dev=00:27 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0 nametype= PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> > > type=PATH msg=audit(1519924845.499:257): item=1 name="/tmp/tmpcontainerid" inode=17729 dev=00:27 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
> > > type=PROCTITLE msg=audit(1519924845.499:257): proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F746D702F746D70636F6E7461696E65726964
> > > type=CONTAINER msg=audit(1519924845.499:257): op=task contid=123458
> > >
> > > See: https://github.com/linux-audit/audit-kernel/issues/90
> > > See: https://github.com/linux-audit/audit-userspace/issues/51
> > > See: https://github.com/linux-audit/audit-testsuite/issues/64
> > > See: https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
> > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > ---
> > >  include/linux/audit.h      |  7 +++++++
> > >  include/uapi/linux/audit.h |  1 +
> > >  kernel/audit.c             | 23 +++++++++++++++++++++++
> > >  kernel/auditsc.c           |  3 +++
> > >  4 files changed, 34 insertions(+)
> >
> > ...
> >
> > > --- a/include/uapi/linux/audit.h
> > > +++ b/include/uapi/linux/audit.h
> > > @@ -115,6 +115,7 @@
> > >  #define AUDIT_REPLACE          1329    /* Replace auditd if this packet unanswerd */
> > >  #define AUDIT_KERN_MODULE      1330    /* Kernel Module events */
> > >  #define AUDIT_FANOTIFY         1331    /* Fanotify access decision */
> > > +#define AUDIT_CONTAINER                1332    /* Container ID */
> >
> > I'm not sure I'm completely sold on the AUDIT_CONTAINER_ID and
> > AUDIT_CONTAINER record type names.  From what I can tell
> > AUDIT_CONTAINER_ID seems to be used for audit container ID management
> > operations, e.g. setting the ID, whereas the AUDIT_CONTAINER is used
> > to tag events with the corresponding audit container ID.  Assuming
> > that is correct, it seems like AUDIT_CONTAINER might be better served
> > if it was named AUDIT_CONTAINER_ID and if we could change
> > AUDIT_CONTAINER_ID to AUDIT_CONTAINER_OP/MGMT/etc.  Thoughts?
>
> Please see discussion at:
>         https://www.redhat.com/archives/linux-audit/2018-May/msg00101.html
>
> I'm fine with changing AUDIT_CONTAINER_ID to AUDIT_CONTAINER_OP/MGMT/etc.

Noted, and while I'm generally a big fan of consistency for things
like this, I think these things are different enough (the loginuid is
recorded as a field, the audit container ID is recorded in a dedicated
record) that we don't need to be bound by LOGINUID's naming
convention.

> > >  #define AUDIT_AVC              1400    /* SE Linux avc denial or grant */
> > >  #define AUDIT_SELINUX_ERR      1401    /* Internal SE Linux Errors */
> > > diff --git a/kernel/audit.c b/kernel/audit.c
> > > index e7478cb..5e150c6 100644
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -2048,6 +2048,29 @@ void audit_log_session_info(struct audit_buffer *ab)
> > >         audit_log_format(ab, " auid=%u ses=%u", auid, sessionid);
> > >  }
> > >
> > > +/*
> > > + * audit_log_contid - report container info
> > > + * @tsk: task to be recorded
> > > + * @context: task or local context for record
> > > + * @op: contid string description
> > > + */
> > > +int audit_log_contid(struct task_struct *tsk,
> > > +                            struct audit_context *context, char *op)
> > > +{
> > > +       struct audit_buffer *ab;
> > > +
> > > +       if (!audit_contid_set(tsk))
> > > +               return 0;
> > > +       /* Generate AUDIT_CONTAINER record with container ID */
> > > +       ab = audit_log_start(context, GFP_KERNEL, AUDIT_CONTAINER);
> > > +       if (!ab)
> > > +               return -ENOMEM;
> > > +       audit_log_format(ab, "op=%s contid=%llu",
> > > +                        op, audit_get_contid(tsk));
> >
> > Can you explain your reason for including an "op" field in this record
> > type?  I've been looking at the rest of the patches in this patchset
> > and it seems to be used more as an indicator of the record's
> > generating context rather than any sort of audit container ID
> > operation.
>
> "action" might work, but that's netfilter and numeric... "kind"?
> Nothing else really seems to fit from a field name, type or lack of
> searchability perspective.

My concern isn't so much the name of the "op" field, although that
does seem wrong, but rather the existence of the field in the first
place.  This audit container ID record (whatever we end up calling it)
exists to attach an audit container ID to an audit event, that's it;
an audit event should have other records which provide the context
(granted, the exact number of records depends on the event and the
system's configuration).  If we are relying on this record to provide
critical information about the audit event other than the audit
container ID, I believe this is a strong indicator that the existing
audit records are lacking and should be augmented.

-- 
paul moore
www.paul-moore.com

  parent reply	other threads:[~2018-07-23 14:17 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-06 16:58 [RFC PATCH ghak90 (was ghak32) V3 00/10] audit: implement container identifier Richard Guy Briggs
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 01/10] audit: add container id Richard Guy Briggs
2018-06-06 17:56   ` Steve Grubb
2018-06-06 20:26     ` Richard Guy Briggs
2018-07-20 22:13   ` Paul Moore
2018-07-24 19:06     ` Richard Guy Briggs
2018-07-24 21:54       ` Paul Moore
2018-07-30 18:47         ` Richard Guy Briggs
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 02/10] audit: log container info of syscalls Richard Guy Briggs
2018-06-06 17:58   ` Steve Grubb
2018-07-20 22:13   ` Paul Moore
2018-07-21 20:29     ` Richard Guy Briggs
2018-07-22 13:32       ` Steve Grubb
2018-07-22 20:55         ` Richard Guy Briggs
2018-07-22 21:03           ` Richard Guy Briggs
2018-07-23 13:19           ` Steve Grubb
2018-07-23 15:11             ` Richard Guy Briggs
2018-07-23 16:48               ` Steve Grubb
2018-07-23 18:31                 ` Paul Moore
2018-07-26  0:51                   ` Richard Guy Briggs
2018-07-31 20:07                     ` Richard Guy Briggs
2018-07-23 13:16       ` Paul Moore [this message]
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 03/10] audit: add containerid support for ptrace and signals Richard Guy Briggs
2018-07-20 22:13   ` Paul Moore
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 04/10] audit: add support for non-syscall auxiliary records Richard Guy Briggs
2018-07-20 22:14   ` Paul Moore
2018-07-24 19:37     ` Richard Guy Briggs
2018-07-24 21:57       ` Paul Moore
2018-07-26 14:30         ` Richard Guy Briggs
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 05/10] audit: add containerid support for tty_audit Richard Guy Briggs
2018-07-20 22:14   ` Paul Moore
2018-07-24 14:07     ` Richard Guy Briggs
2018-07-24 20:36       ` Paul Moore
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 06/10] audit: add containerid filtering Richard Guy Briggs
2018-07-20 22:14   ` Paul Moore
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 07/10] audit: add support for containerid to network namespaces Richard Guy Briggs
2018-07-20 22:14   ` Paul Moore
2018-07-24 14:03     ` Richard Guy Briggs
2018-07-24 20:33       ` Paul Moore
2018-07-26 13:33         ` Richard Guy Briggs
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 08/10] audit: NETFILTER_PKT: record each container ID associated with a netNS Richard Guy Briggs
2018-07-20 22:15   ` Paul Moore
2018-07-24 19:48     ` Steve Grubb
2018-07-24 20:22       ` Paul Moore
2018-07-24 20:55         ` Richard Guy Briggs
2018-07-21 15:32   ` Laura Garcia
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 09/10] debug audit: read container ID of a process Richard Guy Briggs
2018-07-20 22:15   ` Paul Moore
2018-07-21 19:21     ` Richard Guy Briggs
2018-06-06 16:58 ` [RFC PATCH ghak90 (was ghak32) V3 10/10] rfkill: fix spelling mistake contidion to condition Richard Guy Briggs
2018-07-18 20:56   ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHC9VhSUhSDaXzD9fpxm-oK=U4MieekKwY-pypzT=RA1HBw6+Q@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=carlos@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@parisplace.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rgb@redhat.com \
    --cc=serge@hallyn.com \
    --cc=sgrubb@redhat.com \
    --cc=simo@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).