linux-kernel - Re: [PATCH v3 3/3] audit: Audit proc cmdline value

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2002335.9x4iUKkcnh@x2>
Date:	Thu, 16 Jan 2014 06:02:02 -0500
From:	Steve Grubb <sgrubb@...hat.com>
To:	William Roberts <bill.c.roberts@...il.com>
Cc:	"linux-audit@...hat.com" <linux-audit@...hat.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Richard Guy Briggs <rgb@...hat.com>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	akpm@...ux-foundation.org, Stephen Smalley <sds@...ho.nsa.gov>,
	William Roberts <wroberts@...sys.com>
Subject: Re: [PATCH v3 3/3] audit: Audit proc cmdline value

On Wednesday, January 15, 2014 09:08:39 PM William Roberts wrote:
> >> > Try this,
> >> > 
> >> > cp /bin/ls 'test test test'
> >> > auditctll -a always,exit -F arch=b64 -S stat -k test
> >> > ./test\ test\ test './test\ test\ test'
> >> > auditctl -D
> >> > ausearch --start recent --key test
> >> > 
> >> >> On the event of weird chars, it gets hex escaped.
> >> > 
> >> > and its all in 1 lump with no escaping to figure out what is what.
> >> 
> >> Un-escape it. ausearch does this with paths. Then if you need to parse
> >> it, do it.
> > 
> > How can you? When you unescape cmdline for the example I gave, you will
> > have "./test test test ./test test test".  Which program ran and how many
> > arguments were passed? If we are trying to improve on what comm= provides
> > by having the full information, I have to be able to find out exactly
> > what the program name was so it can be used for searching. If that can't
> > be done, then we don't need this addition in its current form.
> 
> In your example, you will have an execve record, with it parsed, will you
> not?

Only if you change your patch.


> cmdline does not necessarily represent the arguments or process name.
> Sometimes it does, sometimes it doesn't. Just treat the thing as one
> string, perhaps do some form of substring matching in a tool. 

You are missing the point. The point is that you are trying to place trust in 
something that can be gamed. The audit system is designed such that it cannot 
be fooled very easily. Each piece of the subject and object are separated so 
that programs can be written to analyze events. What I am trying to say is now 
you are making something that concatenates fields with no way to regroup them 
later to reconstruct what really happened,


> To make this clear, I am not trying to improve on what comm provides.
> comm provides
> 16 chars for per thread name. The key is, its per thread, and can be
> anything. The
> "cmdline" value, is an arbitrary spot that is a global entity for the
> process. So in my change, all things coming into these events will have a
> similar cmdline audit. Which may help in narrowing down on whats going on
> in the system

It needs to be more trustworthy than this.

-Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/