linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: rgb@redhat.com
Cc: Eric Paris <eparis@parisplace.org>,
	linux-audit@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH ghak59 V1 3/6] audit: exclude user records from syscall context
Date: Mon, 23 Jul 2018 17:00:41 -0400	[thread overview]
Message-ID: <CAHC9VhQ3qxHQ6mHhs1JNMg5qr3qJJh2DpD147QWnfsXdM7=rGA@mail.gmail.com> (raw)
In-Reply-To: <20180723164035.wkazolpmpf3mvdxw@madcap2.tricolour.ca>

On Mon, Jul 23, 2018 at 12:43 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2018-07-12 17:46, Richard Guy Briggs wrote:
> > On 2018-06-28 18:11, Paul Moore wrote:
> > > On Thu, Jun 14, 2018 at 4:23 PM Richard Guy Briggs <rgb@redhat.com> wrote:
> > > > Since the function audit_log_common_recv_msg() is shared by a number of
> > > > AUDIT_CONFIG_CHANGE and the entire range of AUDIT_USER_* record types,
> > > > and since the AUDIT_CONFIG_CHANGE message type has been converted to a
> > > > syscall accompanied record type, special-case the AUDIT_USER_* range of
> > > > messages so they remain standalone records.
> > > >
> > > > See: https://github.com/linux-audit/audit-kernel/issues/59
> > > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > > > ---
> > > >  kernel/audit.c | 12 +++++++++---
> > > >  1 file changed, 9 insertions(+), 3 deletions(-)
> > >
> > > I think this is fine, but see my previous comment about combining 2/6
> > > and 3/6 as a safety measure.
> >
> > This one I left as a seperate patch for discussion.  We'd previously
> > talked about connecting all possible records with syscall records if
> > they exist, but this one I'm unsure about, since we don't really care
> > what userspace process is issuing this message.  It is just the message
> > content itself that is important.  Or is it?  Are we concerned about
> > CAP_AUDIT_WRITE holders/abusers and want as much info about them as we
> > can get in case they go rogue or pear-shaped?
>
> I'm waiting on re-spinning this patchset because of this open question.
>
> Is connecting AUDIT_USER* records desirable or a liability?

Like I said, I think special casing the AUDIT_USER* records so they
are *not* associated with other records is okay, and perhaps even the
right thing to do.  The problem is that we don't have the necessary
context (har har) to match any kernel events (and there is the
possibility that there are none) to the userspace generated
AUDIT_USER* event.  Further, I don't think this is something we would
ever be able to solve in a reasonable manner.

> > > > diff --git a/kernel/audit.c b/kernel/audit.c
> > > > index e469234..c8c2efc 100644
> > > > --- a/kernel/audit.c
> > > > +++ b/kernel/audit.c
> > > > @@ -1057,7 +1057,8 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 msg_type)
> > > >         return err;
> > > >  }
> > > >
> > > > -static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > +static void __audit_log_common_recv_msg(struct audit_context *context,
> > > > +                                       struct audit_buffer **ab, u16 msg_type)
> > > >  {
> > > >         uid_t uid = from_kuid(&init_user_ns, current_uid());
> > > >         pid_t pid = task_tgid_nr(current);
> > > > @@ -1067,7 +1068,7 @@ static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > >                 return;
> > > >         }
> > > >
> > > > -       *ab = audit_log_start(audit_context(), GFP_KERNEL, msg_type);
> > > > +       *ab = audit_log_start(context, GFP_KERNEL, msg_type);
> > > >         if (unlikely(!*ab))
> > > >                 return;
> > > >         audit_log_format(*ab, "pid=%d uid=%u", pid, uid);
> > > > @@ -1075,6 +1076,11 @@ static void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > >         audit_log_task_context(*ab);
> > > >  }
> > > >
> > > > +static inline void audit_log_common_recv_msg(struct audit_buffer **ab, u16 msg_type)
> > > > +{
> > > > +       __audit_log_common_recv_msg(audit_context(), ab, msg_type);
> > > > +}
> > > > +
> > > >  int is_audit_feature_set(int i)
> > > >  {
> > > >         return af.features & AUDIT_FEATURE_TO_MASK(i);
> > > > @@ -1341,7 +1347,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
> > > >                                 if (err)
> > > >                                         break;
> > > >                         }
> > > > -                       audit_log_common_recv_msg(&ab, msg_type);
> > > > +                       __audit_log_common_recv_msg(NULL, &ab, msg_type);
> > > >                         if (msg_type != AUDIT_USER_TTY)
> > > >                                 audit_log_format(ab, " msg='%.*s'",
> > > >                                                  AUDIT_MESSAGE_TEXT_MAX,
> > > > --
> > > > 1.8.3.1
> > > >
> > >
> > >
> > > --
> > > paul moore
> > > www.paul-moore.com
> > >
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rgb@redhat.com>
> > Sr. S/W Engineer, Kernel Security, Base Operating Systems
> > Remote, Ottawa, Red Hat Canada
> > IRC: rgb, SunRaycer
> > Voice: +1.647.777.2635, Internal: (81) 32635
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635



-- 
paul moore
www.paul-moore.com

  reply	other threads:[~2018-07-23 21:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14 20:21 [RFC PATCH ghak59 V1 0/6] audit: config_change normalizations and event record gathering Richard Guy Briggs
2018-06-14 20:21 ` [RFC PATCH ghak59 V1 1/6] audit: give a clue what CONFIG_CHANGE op was involved Richard Guy Briggs
2018-06-28 19:41   ` Paul Moore
2018-07-13  0:41     ` Richard Guy Briggs
2018-07-18 21:45       ` Paul Moore
2018-07-19 16:08         ` Richard Guy Briggs
2018-07-19 22:47           ` Paul Moore
2018-07-20 13:27             ` Richard Guy Briggs
2018-07-20 14:21               ` Paul Moore
2018-06-14 20:21 ` [RFC PATCH ghak59 V1 2/6] audit: add syscall information to CONFIG_CHANGE records Richard Guy Briggs
2018-06-28 21:47   ` Paul Moore
2018-06-28 22:10     ` Paul Moore
2018-06-14 20:21 ` [RFC PATCH ghak59 V1 3/6] audit: exclude user records from syscall context Richard Guy Briggs
2018-06-28 22:11   ` Paul Moore
2018-07-12 21:46     ` Richard Guy Briggs
2018-07-23 16:40       ` Richard Guy Briggs
2018-07-23 21:00         ` Paul Moore [this message]
2018-07-24 13:02           ` Richard Guy Briggs
2018-07-24 20:17             ` Paul Moore
2018-06-14 20:21 ` [RFC PATCH ghak59 V1 4/6] audit: hand taken context to audit_kill_trees for syscall logging Richard Guy Briggs
2018-06-28 22:23   ` Paul Moore
2018-07-13 21:44     ` Richard Guy Briggs
2018-06-14 20:21 ` [RFC PATCH ghak59 V1 5/6] audit: move EOE record after kill_trees for exit/free Richard Guy Briggs
2018-06-28 22:25   ` Paul Moore
2018-06-14 20:21 ` [RFC PATCH ghak59 V1 6/6] audit: extend config_change mark/watch/tree rule changes Richard Guy Briggs
2018-06-28 22:28   ` Paul Moore
2018-06-29 12:31     ` Steve Grubb

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='CAHC9VhQ3qxHQ6mHhs1JNMg5qr3qJJh2DpD147QWnfsXdM7=rGA@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=eparis@parisplace.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgb@redhat.com \
    /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).