From: Albert Cahalan <acahalan@gmail.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: "Albert D. Cahalan" <acahalan@cs.uml.edu>,
Al Viro <viro@ftp.linux.org.uk>,
linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH 4/4] pmap: reduced permissions
Date: Mon, 23 Jan 2006 05:20:18 -0500 [thread overview]
Message-ID: <787b0d920601230220r5c7df60dk142d1d637ab4ed48@mail.gmail.com> (raw)
In-Reply-To: <1138009305.2977.28.camel@laptopd505.fenrus.org>
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.
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.
> > In any case, the many existing statically linked executables
> > do cause trouble. Setuid apps are the ones you'd most want
> > to protect.
>
> for this 0400 isn't enough;
because you might fool the app into reading it
> because you can open this file, send the fd
> over a unix socket, and then exec. The process you sent the fd to can
> then read the setuid's program maps file.
You exec what, the setuid executable? For other reasons,
that needs to sever all file descriptors to the /proc files.
They should be returning EBADF for all operations.
Oh dear. I think I see why /proc/*/mem reads are far too
restricted. The file descripters are NOT getting severed???
Hmmm, I'm not finding code to sever them.
Well, that's part of a general problem then, including lack
of the revoke() system call that BSD introduced. This hits
hard with device files. Memory mappings get interesting,
though /dev/zero might make a nice substitute mapping.
next prev parent reply other threads:[~2006-01-23 10:27 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 [this message]
2006-01-25 23:47 ` Nix
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=787b0d920601230220r5c7df60dk142d1d637ab4ed48@mail.gmail.com \
--to=acahalan@gmail.com \
--cc=acahalan@cs.uml.edu \
--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).