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.
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.
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
desireable. 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.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
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.
> 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
> desireable. 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.
Just look at this: cat /proc/1/maps
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)
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: [email protected]
Remember Cernan and Schmitt