<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 6, 2013 at 8:29 AM, Steve Grubb <span dir="ltr"><<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tuesday, November 05, 2013 08:43:03 PM William Roberts wrote:<br>
> So this still seems to be lingering as unresolved in my mind.<br>
<br>
</div>Yes, it is.<br>
<div class="im"><br>
> I need to find out what the remaining reservations are on this feature. I am<br>
> going to try and summarize...<br>
><br>
> Steve Grub:<br>
> 1. Anyway to use argv values as cmdline could be a page (too big)<br>
> 2. Doesn't like disappearing audit entries<br>
<br>
</div>There's more to it than this. I think you are overlooking my main point. This<br>
is a generic problem for all arches. Why don't we just solve the problem once<br>
and for all?<br>
<br>
pgname is limited to 16 bytes. Why? Because that was a reasonable compromise<br>
way back in time when program names were short. With the Android naming<br>
convention 16 bytes is insufficient for anything listing processes like lsof,<br>
ps, netstat, etc. Why can't a new define for prctl be created to set an<br>
extended name? PR_SET_PROCTITLE. From what I saw in past discussions on LKML,<br>
there was a lot of concern that a trojan could change the proc title to<br>
something innocent and hide.<br></blockquote><div><br></div><div>Yes we share that concern. If you want to move something into prctl for this, I am ok with doing that. It makes<br>caching the values a possibility as you can detect when the value needs to be updated. Now to prevent<br>
</div><div>it from having the same issues as setproctitle() I should probably bind this to a capability of some sort, should<br></div><div>I reuse and existing one or create a new one?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
i think that is a losing argument because there are quite a few ways to<br>
accomplish the same thing. That is basically arguing for the status quo and<br>
that means the problem never gets fixed.<br>
<br>
I think with the rise of Android's popularity, there is a growing importance<br>
to fix the problem.<br>
<div class="im"><br>
<br>
> Richard Briggs:<br>
> 1. Can we make it dynamic on/off<br>
<br>
</div>I object to this because we do not have any precedent for configuring a rule to<br>
get something and then another configuration to get all of it. I have worked on<br>
the audit system since 2004. A lot of maintainers have come and gone in that<br>
time. I don't want to see this subsystem have this oddity when they (people<br>
currently contributing patches) lose interest and go away. <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
> Stephen Smalley:<br>
> 1. Can we cache the data for performance reasons<br>
><br>
> So I addressed RGB's issues, which led to one of steve Grub's concerns.<br>
> Which I can address both with if feature on then print cmdline=value else<br>
> print cmdline=(null)<br>
><br>
> Unfortunately the data I want to audit, is the full proc/cmdline entry,<br>
> which I think is the most<br>
> generic way of getting at potential vm data through various fork mazes on<br>
> Android, as well<br>
> as gathering the data on other architectures as well.<br>
<br>
</div>You know, we have the same issue with sudo. We have to get the full command<br>
line. What was done is sudo was patched to collect it and it emits a<br>
AUDIT_USER_CMD event. Maybe this works for you?<br></blockquote><div><br></div><div>I really like this suggestion, the only downfall is that its not directly tied to the audit record, but<br>can be joined together later based on pid and other various identifiers.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-Steve<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> This also prevents us from hitting the<br>
> 16 char width issue on task->comm. Increasing that will result in more<br>
> non-pageable kernel<br>
> memory use, versus my transient use of a page. I also need to make sure I<br>
> can get this<br>
> data before the process terminates, which can happen if I try to acquire it<br>
> in user-space.<br>
><br>
> Also, on error conditions, the last patch version will not print<br>
> cmdline=(null) which is an error and can be trivially corrected.<br>
><br>
> But before I put more time into it, I want to make sure the underlying idea<br>
> will be accepted, architectures, cacheing, print formats etc are all<br>
> trivial.<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Respectfully,<br><br>William C Roberts<br><br>
</div></div>