[ale] cannot open -> /proc/####/mem huh ?

[Jim Kinney]

To sum up, /proc is not a place where humans write. It is literally a view
into kernel processes.
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).
On Feb 7, 2012 6:51 PM, "Michael H. Warfield" <mhw at wittsend.com> wrote:

> On Tue, 2012-02-07 at 11:46 -0500, Courtney Thomas wrote:
> > Jim,
> >
> > As always.... thanks for your reply.
> >
> > You were correct that kvm was apparently attempting to write to /proc~.
> >
> > The puzzle for me is that... there is no /proc/~/mem to which to write,
> > but... apparently this is not permissible by design, as I'm not allowed
> > to change /proc's 555 permissions.
> >
> > Can /proc's permissions be changed from 555 to, say, 755, and if so how;
> > for when I attempt this I get the error that "this is not supported" ? I
> > must say, though, that /proc is the only subdir in it's dir whose
> > permissions are not set 755.
>
> It will not help.  /proc/.../mem is special and there was recently a
> security advisory on how it was handled in 2.6.29 and above (2.6.26 if
> you are on RedHat 6.2 / CentOS 6.2 / SL 6.2).  Permission to write
> to /proc/.../mem was only recently enabled at all and then restricted to
> some very specific circumstances (self and certain tracing / debugging
> functions).  Unfortunately, the handling of those circumstances proved
> to be flawed resulting in an escalation of privilege by a local user on
> the system, which Linus then quickly fixed.
>
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e268337dfe26dfc7efd422a804dbb27977a3cccc
>
> http://www.computerworld.com/s/article/9223675/Linux_vendors_rush_to_patch_privilege_escalation_flaw_after_root_exploits_emerge
> https://rhn.redhat.com/errata/RHSA-2012-0052.html
> https://www.redhat.com/security/data/cve/CVE-2012-0056.html
>
> In kernel space, we do not honor permissions, we enforce them.  If the
> code path says "if foo then return error = EPERM" your screwed no matter
> what you set the permissions to.
>
> If you want to read a really detailed analysis of what it takes to
> exploit this and just how convoluted these exploits can be you can check
> out this blog posting here (includes a link to proof of concept exploit
> code)...
>
> http://blog.zx2c4.com/749
>
> > More mystifyingly... there are other entries that ARE written to in
> > /proc's subdirs. Huh ? I assumed, apparently wrongly, that if a dir's
> > permissions disallowed writing, then it's subdirs would also not allow
> > writing.
> >
> > I am also disallowed from changing proc's 'chown'.
> >
> > Finally, when I -  cat /proc/version -  I get that Linux is version
> > 2.6.16. Does this tell you anything ?
> >
> > Bedazzled and befuddled, as usual  :-)
> >
> > Courtney
> >
> >
> > On 02/06/12 19:27, Jim Kinney wrote:
> > >
> > > The first looks like kvm thinks it should be doing something. If you
> > > aren't running a kvm based server, disable kvm.
> > > The sendmail issue os literally the daemon can't write the file.
> > > Either disk full or permission error.  For unknown reasons sometimes
> > > the var/mail becomes not gtoup writeable. A perm change fixed it and
> > > it didn't reappear.
> > >
> > > On Feb 6, 2012 1:13 PM, "Courtney Thomas"
> > > <courtneycthomas at bellsouth.net <mailto:courtneycthomas at bellsouth.net>>
> > > wrote:
> > >
> > >     What is the significance of this error which is regularly
> appearing in
> > >     /var/log/messages along with.....
> > >
> > >                     kvm_getenvv
> > >
> > >     failed ?
> > >
> > >     This is apparently aroused by gnome's "console-kit-daemon"
> > >
> > >
> ______________________________________________________________________________________________
> > >
> > >
> > >     I'm also getting what I assume is a sendmail complaint as follows:
> > >
> > >         sm-mta cannot write .q###############: permission denied.
> > >
> > >     How can I resolve this as well, pleasely,
> > >
> > >     C.Thomas
> > >     _______________________________________________
> > >     Ale mailing list
> > >     Ale at ale.org <mailto:Ale at ale.org>
> > >     http://mail.ale.org/mailman/listinfo/ale
> > >     See JOBS, ANNOUNCE and SCHOOLS lists at
> > >     http://mail.ale.org/mailman/listinfo
> > >
> > >
> > >
> > > _______________________________________________
> > > Ale mailing list
> > > Ale at ale.org
> > > http://mail.ale.org/mailman/listinfo/ale
> > > See JOBS, ANNOUNCE and SCHOOLS lists at
> > > http://mail.ale.org/mailman/listinfo
> >
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
>
> --
> Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
>   /\/\|=mhw=|\/\/          | (678) 463-0932 |
> http://www.wittsend.com/mhw/
>   NIC whois: MHW9          | An optimist believes we live in the best of
> all
>  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20120208/b048b565/attachment.html