From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Bryan Jacobs <its@easytoremember.us>, linux-kernel@vger.kernel.org
Subject: Re: /proc/[pid]/mem write implications
Date: Sun, 29 Jan 2012 14:19:20 +0000 [thread overview]
Message-ID: <20120129141920.497d96d4@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <4F24BEB5.5070402@gmail.com>
> > But I think that allowing arbitrary processes to write to **their own**
> > memory via a file descriptor might in itself be problematic. Please,
> > help me understand how this is safe.
>
> You will have a sysctl to control if it is writable.
The problem is not that the check is done in write, the problem is more
fundamental - the open should bind to the memory of the executable image
currently running, instead it effectively late binds each write to the
image now being run. That is the root cause.
What's sad about this is that people went and re-introduced the bug and
clearly didn't think to spend 2 minutes asking Google why the checks were
there originally.
2006 thread
http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/1359.html
2004 thread
http://lkml.indiana.edu/hypermail/linux/kernel/0407.0/1169.html
2002 thread
http://www.eros-os.org/pipermail/cap-talk/2002-May/000922.html
If you really want to fix this then you need to bind /proc/self/mem to
the executable image in question, and you need to effectively revoke()
that on exec so it can't be used to pin old images into memory.
Fix that and the rest falls out in the wash.
Alan
next prev parent reply other threads:[~2012-01-29 14:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-29 1:32 /proc/[pid]/mem write implications Bryan Jacobs
2012-01-29 3:36 ` Cong Wang
2012-01-29 14:19 ` Alan Cox [this message]
2012-01-30 8:10 ` Indan Zupancic
2012-01-29 14:21 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120129141920.497d96d4@pyramind.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=its@easytoremember.us \
--cc=linux-kernel@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).