All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vasiliy Kulikov <segoon@openwall.com>
To: Christian Kujau <lists@nerdbynature.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: proc hidepid=2 and SGID programs
Date: Thu, 19 Sep 2013 15:42:02 +0400	[thread overview]
Message-ID: <20130919114202.GA12144@cachalot> (raw)
In-Reply-To: <eb1060ff-d56d-42b7-89f5-a459820edb82@email.android.com>

On Sun, Sep 15, 2013 at 01:58 -0700, Christian Kujau wrote:
> Vasiliy Kulikov <segoon@openwall.com> wrote:
> >> But still, I wonder if this is 
> >> intended behaviour.
> >
> >Yes.
> >
> >If you think such side channel attacks are something you don't care,
> >just turn hidepid off.  That's why it is an option.
> >
> >If you want to turn it off for some users, use gid=XXX.
> 
> Maybe my initial question got lost in the noise: I merely wondered why "pgrep sgid-program" returned nothing but "kill pics off stiff program" was possible. Sure, if that's intended behavior, so be it. I just don't understand the (technical) reasoning behind this.

If process A may ptrace process B, A may kill B.  In this case A may see
any information about B.

If process A may not ptrace process B, A probably still may kill B.  But
A may not see any information about B.

In sense of information gathering hidepid doesn't differ setgid'ed
processes and common processes of another user.  As *some* privileges
differ between a subject and an object, they are considered as being in
different security domains.  Information leakage crossing the
interdomain border between these domains might help an attacker, so it
is denied.

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments

      parent reply	other threads:[~2013-09-19 11:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-07  8:51 proc hidepid=2 and SGID programs Christian Kujau
2013-09-09  6:42 ` Eric W. Biederman
2013-09-10  8:30   ` Christian Kujau
2013-09-10 10:00     ` Eric W. Biederman
2013-09-14 11:14     ` Vasiliy Kulikov
2013-09-15  8:58       ` Christian Kujau
2013-09-15  9:01         ` Christian Kujau
2013-09-19 11:42         ` Vasiliy Kulikov [this message]

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=20130919114202.GA12144@cachalot \
    --to=segoon@openwall.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists@nerdbynature.de \
    /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.