From: Steve Grubb <sgrubb@redhat.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: linux-audit@redhat.com, linux-security-module@vger.kernel.org
Subject: Re: [PATCH] TaskTracker : Simplified thread information tracker.
Date: Sat, 27 Sep 2014 09:14:40 -0400 [thread overview]
Message-ID: <20140927091440.6fe54f43@ivy-bridge> (raw)
In-Reply-To: <201409271002.JAH52667.FtSOOHOQLFFMJV@I-love.SAKURA.ne.jp>
On Sat, 27 Sep 2014 10:02:44 +0900
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
> May I continue proposing this functionality?
>From the audit perspective, sure. I think we were expecting a revised
patch after the comments. Other groups may have different thoughts,
though.
-Steve
> I want to identify where
> bash is executed from in the RHEL servers in order to assess
> possibility of damage caused by CVE-2014-6271.
>
> Tetsuo Handa wrote:
> > Thank you for your comment, Steve.
> >
> > Steve Grubb wrote:
> > > On Monday, June 23, 2014 09:14:35 PM Tetsuo Handa wrote:
> > >> Any comments on this proposal?
> > >
> > > subj= is the wrong way to record this. The subj field name is for
> > > process labels. When field names get re-used for different
> > > purposes, it causes lots of problems in being able to assign
> > > meaning and correctly use it in analysis. I would suggest using
> > > phist= for process history or something like that. Please don't
> > > re-use subj for this.
> >
> > This was just a sample implementation. If this proposal is
> > acceptable as a patch to auditing subsystem, I'm happy to update
> > not to re-use subj= field and not to occupy LSM. An updated version
> > is attached.
> >
> > > Also, the comm file is under control of the user. What if they
> > > create a program "sshd=>crond"? Would that throw off the
> > > analysis? How do you ensure user supplied names do not contain
> > > symbols that you are using to denote parentage?
> >
> > OK. I added '=' in comm name to the list of need-to-escape bytes.
> >
> > By the way, audit_string_contains_control() treats *p == '"' || *p
> > < 0x21 || *p > 0x7e as need-to-escape bytes. Thus, 0x20 from
> > audit_log_untrustedstring() is a need-to-escape byte. However, I
> > can see that 0x20 from userspace programs is emitted without
> > escaping.
> >
> > type=USER_START msg=audit(1403741835.270:16): user pid=1870 uid=0
> > auid=0 ses=1 msg='op=login id=0 exe="/usr/sbin/sshd"
> > hostname=192.168.0.1 addr=192.168.0.1 terminal=/dev/pts/0
> > res=success'
> >
> > Where can I find which bytes in $value need to be escaped when
> > emitting a record like name='$value' ? Is 0x20 in $value permitted?
> >
> > > Also, would you consider adding this information as a auxiliary
> > > record rather than as part of a syscall record? The advantage is
> > > it can be filtered or searched for. We recently did this for
> > > PROCTITLE information. Perhaps this fits better as a PROCHIST
> > > auxiliary record?
> >
> > I changed to use auxiliary record and noticed a difference.
> > The previous version emitted the history for type=USER_LOGIN case
> >
> > type=USER_LOGIN msg=audit(1400879947.084:24): pid=4308 uid=0
> > auid=0 ses=2
> > subj="swapper/0(2014/05/23-21:17:30)=>init(2014/05/23-21:17:33)=>
> > switch_root(2014/05/23-21:17:34)=>init(2014/05/23-21:17:34)=>
> > sh(2014/05/23-21:17:56)=>mingetty(2014/05/23-21:17:56)=>
> > login(2014/05/23-21:19:05)" msg='op=login id=0 exe="/bin/login"
> > hostname=? addr=? terminal=tty1 res=success'
> >
> > but current version does not emit it for type=USER_LOGIN case.
> > Does auxiliary record work with only type=SYSCALL case (and
> > therefore I should use CONFIG_AUDITSYSCALL rather than CONFIG_AUDIT
> > in the patch below) ?
> >
> > Regards.
> > ----------
> > >From d015533ce544feb8922fcbf023017c82bd79a9ac Mon Sep 17 00:00:00
> > >2001
> > From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Date: Thu, 26 Jun 2014 09:39:14 +0900
> > Subject: [PATCH] audit: Emit history of thread's comm name.
> >
> > When an unexpected system event (e.g. reboot) occurs, the
> > administrator may want to identify which application triggered the
> > event. System call auditing could be used for recording such event.
> > However, the audit log may not be able to provide sufficient
> > information for identifying the application because the audit log
> > does not reflect how the program was executed.
> >
> > This patch adds ability to trace how the program was executed and
> > emit it as an auxiliary record in the form of comm name and time
> > stamp pairs as of execve().
> >
> > type=UNKNOWN[1329] msg=audit(1403741314.019:22): history='
> > swapper/0(2014/06/26-09:06:04)=>init(2014/06/26-09:06:10)=>
> > switch_root(2014/06/26-09:06:13)=>init(2014/06/26-09:06:13)=>
> > sh(2014/06/26-00:06:27)=>rc(2014/06/26-00:06:27)=>
> > S55sshd(2014/06/26-00:06:35)=>sshd(2014/06/26-00:06:35)=>
> > sshd(2014/06/26-00:06:40)=>bash(2014/06/26-00:06:43)=>
> > tail(2014/06/26-00:08:34)'
> >
> > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > ---
> > fs/exec.c | 1 +
> > include/linux/audit.h | 23 +++++++++++-
> > include/linux/init_task.h | 9 ++++
> > include/linux/sched.h | 5 ++
> > include/uapi/linux/audit.h | 1 +
> > kernel/audit.c | 90
> > ++++++++++++++++++++++++++++++++++++++++++++
> > kernel/auditsc.c | 19 +++++++++ 7 files changed, 147
> > insertions(+), 1 deletions(-)
> >
next prev parent reply other threads:[~2014-09-27 13:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 12:44 [PATCH] TaskTracker : Simplified thread information tracker Tetsuo Handa
2014-06-23 12:14 ` Tetsuo Handa
2014-06-24 14:00 ` Steve Grubb
2014-06-26 11:40 ` Tetsuo Handa
2014-09-27 1:02 ` Tetsuo Handa
2014-09-27 13:14 ` Steve Grubb [this message]
2014-09-27 15:13 ` Tetsuo Handa
2014-09-27 15:40 ` Steve Grubb
2014-09-28 10:24 ` [PATCH] audit: Emit history of thread's comm name Tetsuo Handa
2014-10-07 21:30 ` [PATCH] TaskTracker : Simplified thread information tracker Richard Guy Briggs
2014-10-10 12:40 ` Tetsuo Handa
2014-10-10 12:49 ` Richard Guy Briggs
2015-01-04 11:50 ` Tetsuo Handa
2015-01-05 18:07 ` Richard Guy Briggs
2015-01-12 6:13 ` Tetsuo Handa
2015-01-12 15:14 ` Steve Grubb
2015-01-12 20:51 ` Paul Moore
2015-01-20 13:20 ` Tetsuo Handa
2015-01-12 15:21 ` Richard Guy Briggs
2015-01-19 15:25 ` Richard Guy Briggs
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=20140927091440.6fe54f43@ivy-bridge \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.