lkml.org 
[lkml]   [2006]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4] pmap: reduced permissions
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-23 11:30    [W:0.041 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site