Messages in this thread | | | Date | Mon, 23 Jan 2006 05:20:18 -0500 | From | Albert Cahalan <> | Subject | Re: [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/
| |