<p>To sum up, /proc is not a place where humans write. It is literally a view into kernel processes.<br>
There are some runtime variables that can be tweaked by admins. For most situations these are best handled by sysctl. Most, if not all of these, have been relocated to /sys (or I have this all wrong and backwards between sys and proc).</p>

<div class="gmail_quote">On Feb 7, 2012 6:51 PM, &quot;Michael H. Warfield&quot; &lt;<a href="mailto:mhw@wittsend.com">mhw@wittsend.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 2012-02-07 at 11:46 -0500, Courtney Thomas wrote:<br>
&gt; Jim,<br>
&gt;<br>
&gt; As always.... thanks for your reply.<br>
&gt;<br>
&gt; You were correct that kvm was apparently attempting to write to /proc~.<br>
&gt;<br>
&gt; The puzzle for me is that... there is no /proc/~/mem to which to write,<br>
&gt; but... apparently this is not permissible by design, as I&#39;m not allowed<br>
&gt; to change /proc&#39;s 555 permissions.<br>
&gt;<br>
&gt; Can /proc&#39;s permissions be changed from 555 to, say, 755, and if so how;<br>
&gt; for when I attempt this I get the error that &quot;this is not supported&quot; ? I<br>
&gt; must say, though, that /proc is the only subdir in it&#39;s dir whose<br>
&gt; permissions are not set 755.<br>
<br>
It will not help.  /proc/.../mem is special and there was recently a<br>
security advisory on how it was handled in 2.6.29 and above (2.6.26 if<br>
you are on RedHat 6.2 / CentOS 6.2 / SL 6.2).  Permission to write<br>
to /proc/.../mem was only recently enabled at all and then restricted to<br>
some very specific circumstances (self and certain tracing / debugging<br>
functions).  Unfortunately, the handling of those circumstances proved<br>
to be flawed resulting in an escalation of privilege by a local user on<br>
the system, which Linus then quickly fixed.<br>
<br>
<a href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e268337dfe26dfc7efd422a804dbb27977a3cccc" target="_blank">http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e268337dfe26dfc7efd422a804dbb27977a3cccc</a><br>

<a href="http://www.computerworld.com/s/article/9223675/Linux_vendors_rush_to_patch_privilege_escalation_flaw_after_root_exploits_emerge" target="_blank">http://www.computerworld.com/s/article/9223675/Linux_vendors_rush_to_patch_privilege_escalation_flaw_after_root_exploits_emerge</a><br>

<a href="https://rhn.redhat.com/errata/RHSA-2012-0052.html" target="_blank">https://rhn.redhat.com/errata/RHSA-2012-0052.html</a><br>
<a href="https://www.redhat.com/security/data/cve/CVE-2012-0056.html" target="_blank">https://www.redhat.com/security/data/cve/CVE-2012-0056.html</a><br>
<br>
In kernel space, we do not honor permissions, we enforce them.  If the<br>
code path says &quot;if foo then return error = EPERM&quot; your screwed no matter<br>
what you set the permissions to.<br>
<br>
If you want to read a really detailed analysis of what it takes to<br>
exploit this and just how convoluted these exploits can be you can check<br>
out this blog posting here (includes a link to proof of concept exploit<br>
code)...<br>
<br>
<a href="http://blog.zx2c4.com/749" target="_blank">http://blog.zx2c4.com/749</a><br>
<br>
&gt; More mystifyingly... there are other entries that ARE written to in<br>
&gt; /proc&#39;s subdirs. Huh ? I assumed, apparently wrongly, that if a dir&#39;s<br>
&gt; permissions disallowed writing, then it&#39;s subdirs would also not allow<br>
&gt; writing.<br>
&gt;<br>
&gt; I am also disallowed from changing proc&#39;s &#39;chown&#39;.<br>
&gt;<br>
&gt; Finally, when I -  cat /proc/version -  I get that Linux is version<br>
&gt; 2.6.16. Does this tell you anything ?<br>
&gt;<br>
&gt; Bedazzled and befuddled, as usual  :-)<br>
&gt;<br>
&gt; Courtney<br>
&gt;<br>
&gt;<br>
&gt; On 02/06/12 19:27, Jim Kinney wrote:<br>
&gt; &gt;<br>
&gt; &gt; The first looks like kvm thinks it should be doing something. If you<br>
&gt; &gt; aren&#39;t running a kvm based server, disable kvm.<br>
&gt; &gt; The sendmail issue os literally the daemon can&#39;t write the file.<br>
&gt; &gt; Either disk full or permission error.  For unknown reasons sometimes<br>
&gt; &gt; the var/mail becomes not gtoup writeable. A perm change fixed it and<br>
&gt; &gt; it didn&#39;t reappear.<br>
&gt; &gt;<br>
&gt; &gt; On Feb 6, 2012 1:13 PM, &quot;Courtney Thomas&quot;<br>
&gt; &gt; &lt;<a href="mailto:courtneycthomas@bellsouth.net">courtneycthomas@bellsouth.net</a> &lt;mailto:<a href="mailto:courtneycthomas@bellsouth.net">courtneycthomas@bellsouth.net</a>&gt;&gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;     What is the significance of this error which is regularly appearing in<br>
&gt; &gt;     /var/log/messages along with.....<br>
&gt; &gt;<br>
&gt; &gt;                     kvm_getenvv<br>
&gt; &gt;<br>
&gt; &gt;     failed ?<br>
&gt; &gt;<br>
&gt; &gt;     This is apparently aroused by gnome&#39;s &quot;console-kit-daemon&quot;<br>
&gt; &gt;<br>
&gt; &gt;     ______________________________________________________________________________________________<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;     I&#39;m also getting what I assume is a sendmail complaint as follows:<br>
&gt; &gt;<br>
&gt; &gt;         sm-mta cannot write .q###############: permission denied.<br>
&gt; &gt;<br>
&gt; &gt;     How can I resolve this as well, pleasely,<br>
&gt; &gt;<br>
&gt; &gt;     C.Thomas<br>
&gt; &gt;     _______________________________________________<br>
&gt; &gt;     Ale mailing list<br>
&gt; &gt;     <a href="mailto:Ale@ale.org">Ale@ale.org</a> &lt;mailto:<a href="mailto:Ale@ale.org">Ale@ale.org</a>&gt;<br>
&gt; &gt;     <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
&gt; &gt;     See JOBS, ANNOUNCE and SCHOOLS lists at<br>
&gt; &gt;     <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Ale mailing list<br>
&gt; &gt; <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
&gt; &gt; <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
&gt; &gt; See JOBS, ANNOUNCE and SCHOOLS lists at<br>
&gt; &gt; <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Ale mailing list<br>
&gt; <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
&gt; <a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
&gt; See JOBS, ANNOUNCE and SCHOOLS lists at<br>
&gt; <a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br>
--<br>
Michael H. Warfield (AI4NB) | <a href="tel:%28770%29%20985-6132" value="+17709856132">(770) 985-6132</a> |  mhw@WittsEnd.com<br>
   /\/\|=mhw=|\/\/          | <a href="tel:%28678%29%20463-0932" value="+16784630932">(678) 463-0932</a> |  <a href="http://www.wittsend.com/mhw/" target="_blank">http://www.wittsend.com/mhw/</a><br>
   NIC whois: MHW9          | An optimist believes we live in the best of all<br>
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!<br>
<br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div>