[PATCH] audit: Add cmdline to taskinfo output

[William Roberts]

On Thu, Oct 31, 2013 at 7:36 AM, Steve Grubb <sgrubb at redhat.com> wrote:

> On Wednesday, October 30, 2013 01:18:13 PM William Roberts wrote:
> > On Wed, Oct 30, 2013 at 12:42 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > > > > Again... the comm field got cut off and now I have no idea again.
> > >
> > > Which is the same as all arches. What I'm trying to say is that all
> arches
> > > would benefit from fixing this problem. I don't like the idea of it
> > > getting fixed
> > > for one platform and leaving it for all others to figure out another
> day.
> >
> > By arches your don't mean arm right?
>
> Any piece of hardware support the audit code. For example, x86_64/S390/PPC,
> etc.
>
>
> > This code runs the same on other architectures. If you mean platforms,
> like
> > Android, vs some other Linux distro, then yes I want a generic approach,
> > which I think cmdline gets us... no mater how many layers of VM
> exec/forking
> > indirection hell you may find yourself in, you at least get a chance at
> > what started the chain. On Android, that happens to be the packagename.
>
> What I'm suggesting is to fix "comm" to have more characters than 16.
> Which may
> mean getting it from somewhere else, or allowing a slightly bigger
> storage, or
> allowing an alternate storage in the audit context.
>

My point is, that comm and cmdline often times differ. JVMs oftren times
set the
comm field to some generated thread name via pthreads/prctl interface.
Since they
often times differ, I need them both. I even sent an example of this where
the comm
field was not what I wanted, and the cmdline field was.


>
>
> > > Is there some reason that the length of that field must be set to 16?
> I've
> > > seen
> > > user id numbers increased by a config option. It might be that the
> naming
> > > convention of android apps is enough to get a change.
> > >
> > > > I think exe= in the audit logs is essentially arg[0]... so thats not
> > >
> > > going
> > >
> > > > to work here,
> >
> > We can't change the naming convention of andorid apps, too large of an
> > ecosystem to change and no real easy way to be backwards compatible. That
> > one is off the table.
>
> That wasn't my suggestion. I was meaning that because of the andriod naming
> convention the current program name storage is useless and might need
> fixing.
>

I have patches that set the comm field to the package name submitted to
Android, but Dalvik
during execution will adjust the comm field to account for async task
naming etc. But even if
we fixed the VM to NOT do this... processes can still have a differing comm
title
and cmdline entry.


>
>
> > I have compiled kernels in the past with custom COMM widths, but the
> memory
> > footprint goes up, at least here were not keeping a bunch of possibly
> unused
> > data around in the kernel plus we're not allocating anything on the
> common
> > case of it being turned off.
>
> I don't like the idea of fields appearing and disappearing. The complaint
> is
> "comm" is meaningless. Let's fix that.
>

Its not that the field is disappearing, its just whether or not you want
the value
printed out. cmdline=(null) vs cmdline="something". That's a trivial change
of not
making it dynamic which is what my first patch did but Richard Briggs
suggested
making it a dynamic feature and I was pretty ok with that.

So the bottom line is, I need comm and cmdline, any other approach needs to
address
the fact that things can happen via fork and not only exec as well as
differing comm and
cmdline fields.

-- 
Respectfully,

William C Roberts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20131031/a8131fbf/attachment.htm>