On Mon, Oct 28, 2002 at 01:01:02AM -0500, Albert D. Cahalan wrote:
> jw schultz writes:
> > On Sun, Oct 27, 2002 at 03:24:28AM -0500, Albert D. Cahalan wrote:
>
> >> As a non-root user:
> >>
> >> a. I can't do readlink() on /proc/1/exe ("ls -l /proc/1/exe")
> >> b. I can do "cat /proc/1/maps" to see what files are mapped
> >>
> >> That's backwards. If a user can read /proc/1/cmdline, then
> >> they might as well be permitted to readlink() on /proc/1/exe
> >> as well. Reading /proc/1/maps is quite another matter,
> >> exposing more info than the (prohibited) /proc/1/fd/* does.
> >
> > It seems to have been this way since at least 2.2. It isn't
> > exclusive to the /proc/*/exe. It applies to all symlinks in
> > /proc/$pid.
>
> Guessing:
>
> 1. readlink and follow permissions were not distinct
> 2. symlink following in /proc wasn't done normally
> 3. therefore, readlink implied access to the target's data
>
> Rather than fix #1 or #2, readlink() got restricted.
That is my guess regarding 2.2 (and earlier). 2.4 and
future it is explicitly tested in proc_fd_readlink() which
only applies to the links in /proc/$pid
> > As near as i can tell it seems to be a
> > functional-equivalency carryover from 2.2. It isn't causing
> > much harm but i do wonder if this is intentional and if so,
> > why. I'm at a loss to see why refusing to allow non-owners
> > to identify a process's cwd, exe, and root would be
> > desirable. The only other things we refuse are mem, fd/
> > and eviron, the reasons for which are obvious and the
> > restrictions are per-file rather than as a class.
>
> Being able to readlink() in the fd directory is much less
> revealing than the content of the maps file. IMHO both of
> them should be restricted, but the "maps" file matters more.
And i can so no reason why either should be restricted. There
is no confidential information therein and these symlinks do
not open any access that wouldn't already exist.
> Just look at this: cat /proc/1/maps
So what? If the reason for your post was to suggest that
the maps file should be 400 then you should have said so. I
don't think doing so would have any security value unless
you believe in security through obscurity. The only
indiscretion i can think of would be to reveal the existence
of a file in a directory with --x perms (occasionally good for privacy,
always poor for security) in which case you would want maps
and all the /proc/$pid/* links restricted.
> This all looks completely mixed up. Users SHOULD NOT be able
> to read /proc/1/maps, but SHOULD be able to readlink at least
> any /proc/1/* symlink that has meaning in the current namespace.
> (so not if the observer is in a chroot environment)
Proc mounted inside a chrooted or jailed namespace is a
completely different issue. As would be the value of the
links where the observed is chrooted.
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.wsRemember Cernan and Schmitt - 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/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:35 EST