<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 11, 2013 at 7:52 AM, William Roberts <span dir="ltr"><<a href="mailto:bill.c.roberts@gmail.com" target="_blank">bill.c.roberts@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Previously I posted a patch to print during audit the proc/self/cmdline value.<div><br></div><div>Steve Grubb had some concerns, as he has seen this before of "lets fix this</div>
<div>once and for all, properly"</div>
<div><br></div><div>The major concerns (consolidated) were:</div><div>1. The value could be set by the process at runtime and therefore easily spoofed</div><div>2. The value could be too large (truncated at page level)</div>

<div>3. Performance concerns of copying a whole page from userspace on every record</div><div><br></div><div>Steve Grubb proposed adding some field in struct task and extending the prctl interface</div><div>for getter/setter.</div>

<div><br></div><div>My concern here, is the spoofing portion. Obviously this needs to be controlled by someone</div><div>other then the process to which this applies, right now the PR_SET_NAME would have the</div><div>same issue as cmdline, except be truncated to 16 bytes.</div>

<div><br></div><div>I don't see any capabilities or restrictions on existing prctl interfaces, outside of the MAC hook.</div><div><br clear="all"><div>Can anyone chime in and either tell me my concerns are over kill or what here?</div>

<div><br></div><div>I don't want to go coding down a bad path on this.</div><span class="HOEnZb"><font color="#888888"><div><br></div><br></font></span></div></div></blockquote><div><br></div><div> </div></div>Bump, bringing this back up...</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I don't think its correct or full understand  Steve Grubbs' complaint that auditing cmdline isn't generic enough.</div><div class="gmail_extra">Adding another field, to store the data in, adding a prctl interface, etc, just ends up with another spot</div>
<div class="gmail_extra">that someone can add data to for auditing, which cmdline already gives us. Now he also brought up</div><div class="gmail_extra">that the value can be spoofed, much like a lot of other audit data currently, so that really doesn't matter</div>
<div class="gmail_extra">IMO then.</div><div class="gmail_extra"><br>Sending an event from userspace to the kernel, is a bit limited in its not very generic. cmdline</div><div class="gmail_extra">seems to give us what we want, without hacking on everything in userspace.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The two concerns I see as valid are:</div><div class="gmail_extra">1. Performance - Steve Smalley</div><div class="gmail_extra">2. Do not make it dynamic - Steve Grubb</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Again though, those are not fundamentally unchangeable things. At the end of the day, I am trying</div><div class="gmail_extra">to gather the requirements so I can get this merged upstream. Any help?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Bill</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>