Re: [PATCH 4/4] pmap: reduced permissions

[Albert Cahalan]

On 1/23/06, Arjan van de Ven <arjan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/