Re: Follow up on auditing cmdline
On Tuesday, November 05, 2013 08:43:03 PM William Roberts wrote:
So this still seems to be lingering as unresolved in my mind.
Yes, it is.
I need to find out what the remaining reservations are on this
feature. I am
going to try and summarize...
Steve Grub:
1. Anyway to use argv values as cmdline could be a page (too big)
2. Doesn't like disappearing audit entries
There's more to it than this. I think you are overlooking my main point. This
is a generic problem for all arches. Why don't we just solve the problem once
and for all?
pgname is limited to 16 bytes. Why? Because that was a reasonable compromise
way back in time when program names were short. With the Android naming
convention 16 bytes is insufficient for anything listing processes like lsof,
ps, netstat, etc. Why can't a new define for prctl be created to set an
extended name? PR_SET_PROCTITLE. From what I saw in past discussions on LKML,
there was a lot of concern that a trojan could change the proc title to
something innocent and hide.
i think that is a losing argument because there are quite a few ways to
accomplish the same thing. That is basically arguing for the status quo and
that means the problem never gets fixed.
I think with the rise of Android's popularity, there is a growing importance
to fix the problem.
Richard Briggs:
1. Can we make it dynamic on/off
I object to this because we do not have any precedent for configuring a rule to
get something and then another configuration to get all of it. I have worked on
the audit system since 2004. A lot of maintainers have come and gone in that
time. I don't want to see this subsystem have this oddity when they (people
currently contributing patches) lose interest and go away.
Stephen Smalley:
1. Can we cache the data for performance reasons
So I addressed RGB's issues, which led to one of steve Grub's concerns.
Which I can address both with if feature on then print cmdline=value else
print cmdline=(null)
Unfortunately the data I want to audit, is the full proc/cmdline entry,
which I think is the most
generic way of getting at potential vm data through various fork mazes on
Android, as well
as gathering the data on other architectures as well.
You know, we have the same issue with sudo. We have to get the full command
line. What was done is sudo was patched to collect it and it emits a
AUDIT_USER_CMD event. Maybe this works for you?
-Steve
This also prevents us from hitting the
16 char width issue on task->comm. Increasing that will result in more
non-pageable kernel
memory use, versus my transient use of a page. I also need to make sure I
can get this
data before the process terminates, which can happen if I try to acquire it
in user-space.
Also, on error conditions, the last patch version will not print
cmdline=(null) which is an error and can be trivially corrected.
But before I put more time into it, I want to make sure the underlying idea
will be accepted, architectures, cacheing, print formats etc are all
trivial.