lkml.org 
[lkml]   [2002]   [Oct]   [28]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSun, 27 Oct 2002 23:50:12 -0800
Fromjw schultz <>
SubjectRe: warped security
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.ws
		Remember 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/

\
 
 \ /
  Last update: 2005-03-22 12:30    [W:0.091 / U:0.210 seconds]
©2003-2008 Jasper Spaans