linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nix <nix@esperi.org.uk>
To: Albert Cahalan <acahalan@gmail.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
	"Albert D. Cahalan" <acahalan@cs.uml.edu>,
	"Jakub Jelinek <jakub@redhat.com> Al Viro"
	<viro@ftp.linux.org.uk>,
	linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH 4/4] pmap: reduced permissions
Date: Wed, 25 Jan 2006 23:47:56 +0000	[thread overview]
Message-ID: <87r76vrhsj.fsf@amaterasu.srvr.nix> (raw)
In-Reply-To: <787b0d920601230220r5c7df60dk142d1d637ab4ed48@mail.gmail.com> (Albert Cahalan's message of "23 Jan 2006 10:28:34 -0000")

On 23 Jan 2006, Albert Cahalan said:
> On 1/23/06, Arjan van de Ven <arjan@infradead.org> wrote:
>> On Mon, 2006-01-23 at 04:28 -0500, Albert Cahalan wrote:
> 
>> > I tend to think that glibc should not be reading this file.
>> > What excuse is there?
>>
>> glibc needs to be able to find out if a certain address is writable. (eg
>> mapped "w"). The only way available for that is... reading the maps
>> file.
> 
> What the heck for? That's gross.

Ironically enough, it's security. :)

> If glibc is just providing this info for apps, there should be a
> system call for it. Otherwise, being the C library, glibc can
> damn well remember what it did.

Nah, it's used for vfprintf() argument-area checking.

Specifically, it's the Linux implementation of __readonly_area(),
located in sysdeps/unix/sysv/linux/readonly-area.c in glibc-3.4-to-be,
and used by vfprintf() on behalf of __vfprintf_chk(). Calls to this
function (and the other __*_chk() functions) are expanded by glibc's
string headers and generated by GCC 4.1+ automatically when possible
(and by GCCs out there in the field: this patch is shipped by RH
already, known as FORTIFY_SOURCE).

FORTIFY_SOURCE zaps a whole class of security vulnerabilities stone
dead. Breaking it would be a bad idea. Therefore, /proc/self/maps has to
remain readable, even in setuid programs, because setuid programs are
one class of programs for which FORTIFY_SOURCE is crucial.

[Jakub added to Cc:, he can defend his own code much better than I can]

-- 
`Everyone has skeletons in the closet.  The US has the skeletons
 driving living folks into the closet.' --- Rebecca Ore

  reply	other threads:[~2006-01-25 23:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-22 22:19 [PATCH 4/4] pmap: reduced permissions Albert D. Cahalan
2006-01-23  6:10 ` Arjan van de Ven
2006-01-23  9:28   ` Albert Cahalan
2006-01-23  9:41     ` Arjan van de Ven
2006-01-23 10:20       ` Albert Cahalan
2006-01-25 23:47         ` Nix [this message]
2006-01-26  1:45           ` Albert Cahalan
2006-01-26  7:21             ` Arjan van de Ven
2006-01-26  7:54             ` Nix

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=87r76vrhsj.fsf@amaterasu.srvr.nix \
    --to=nix@esperi.org.uk \
    --cc=acahalan@cs.uml.edu \
    --cc=acahalan@gmail.com \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ftp.linux.org.uk \
    /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).