On Mon, Nov 11, 2013 at 7:52 AM, William Roberts <bill.c.roberts@gmail.com> wrote:
Previously I posted a patch to print during audit the proc/self/cmdline value.

Steve Grubb had some concerns, as he has seen this before of "lets fix this
once and for all, properly"

The major concerns (consolidated) were:
1. The value could be set by the process at runtime and therefore easily spoofed
2. The value could be too large (truncated at page level)
3. Performance concerns of copying a whole page from userspace on every record

Steve Grubb proposed adding some field in struct task and extending the prctl interface
for getter/setter.

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

I don't see any capabilities or restrictions on existing prctl interfaces, outside of the MAC hook.

Can anyone chime in and either tell me my concerns are over kill or what here?

I don't want to go coding down a bad path on this.



 
Bump, bringing this back up...

I don't think its correct or full understand  Steve Grubbs' complaint that auditing cmdline isn't generic enough.
Adding another field, to store the data in, adding a prctl interface, etc, just ends up with another spot
that someone can add data to for auditing, which cmdline already gives us. Now he also brought up
that the value can be spoofed, much like a lot of other audit data currently, so that really doesn't matter
IMO then.

Sending an event from userspace to the kernel, is a bit limited in its not very generic. cmdline
seems to give us what we want, without hacking on everything in userspace.

The two concerns I see as valid are:
1. Performance - Steve Smalley
2. Do not make it dynamic - Steve Grubb

Again though, those are not fundamentally unchangeable things. At the end of the day, I am trying
to gather the requirements so I can get this merged upstream. Any help?

Bill