All of lore.kernel.org
 help / color / mirror / Atom feed
From: jw schultz <jw@pegasys.ws>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: warped security
Date: Sun, 27 Oct 2002 10:45:48 -0800	[thread overview]
Message-ID: <20021027184548.GB21165@pegasys.ws> (raw)
In-Reply-To: <200210270824.g9R8OSI269870@saturn.cs.uml.edu>

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:		jw@pegasys.ws

		Remember Cernan and Schmitt

  reply	other threads:[~2002-10-27 18:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-27  8:24 warped security Albert D. Cahalan
2002-10-27 18:45 ` jw schultz [this message]
2002-10-28  6:01   ` Albert D. Cahalan
2002-10-28  7:50     ` jw schultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021027184548.GB21165@pegasys.ws \
    --to=jw@pegasys.ws \
    --cc=acahalan@cs.uml.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.