All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.