From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH] TaskTracker : Simplified thread information tracker. Date: Sat, 27 Sep 2014 09:14:40 -0400 Message-ID: <20140927091440.6fe54f43@ivy-bridge> References: <201405232144.JFB30480.OVMOOSFtQJHLFF@I-love.SAKURA.ne.jp> <201406232114.EJD56725.JFOOHQFMFOVSLt@I-love.SAKURA.ne.jp> <6185690.zhavPjVDeb@x2> <201406262040.BGC30243.FFMLHOVQOOFSJt@I-love.SAKURA.ne.jp> <201409271002.JAH52667.FtSOOHOQLFFMJV@I-love.SAKURA.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <201409271002.JAH52667.FtSOOHOQLFFMJV@I-love.SAKURA.ne.jp> Sender: linux-security-module-owner@vger.kernel.org To: Tetsuo Handa Cc: linux-audit@redhat.com, linux-security-module@vger.kernel.org List-Id: linux-audit@redhat.com On Sat, 27 Sep 2014 10:02:44 +0900 Tetsuo Handa 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 > > 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 > > --- > > 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(-) > >