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: Sat, 14 Sep 2013 15:14:26 +0400 [thread overview]
Message-ID: <20130914111426.GB4663@cachalot> (raw)
In-Reply-To: <alpine.DEB.2.11.1309100124020.6509@trent.utfs.org>
On Tue, Sep 10, 2013 at 01:30 -0700, Christian Kujau wrote:
> On Sun, 8 Sep 2013 at 23:42, Eric W. Biederman wrote:
> > I don't have a clue why anyone would want to hide processes, and make
> > their own lives more difficult.
>
> Oh, there are plenty of usescases, I'm sure. And I for one am thankful
> that this process hiding option made it into the kernel. Or, to answer in
> another way: why would anyone want to see other peoples processes?
The point is that quite many information about other user processes
which can be obtained from procfs can be used in side channel attacks
directed to either confidentiality or even privilege escalation.
> > The check with hidepid is can you ptrace the process. I expect there
> > is something with those sgid processes that keeps you from ptracing
> > them.
>
> Indeed, I cannot strace the process.
Right.
> 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.
--
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
next prev parent reply other threads:[~2013-09-14 11:14 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 [this message]
2013-09-15 8:58 ` Christian Kujau
2013-09-15 9:01 ` Christian Kujau
2013-09-19 11:42 ` Vasiliy Kulikov
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=20130914111426.GB4663@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox