Hi,
I was wondering why I cannot see processes that were started from SGID
programs:
================================
$ grep ^proc /proc/mounts
proc /proc proc rw,nosuid,nodev,noexec,relatime,hidepid=2 0 0
$ ls -n `which ssh-agent`
-rwxr-sr-x 1 0 103 132748 Feb 8 2013 /usr/bin/ssh-agent
$ eval `ssh-agent`
Agent pid 3177
$ ps -o euid,ruid,suid,egid,rgid,sgid,pid,comm -p 3177
EUID RUID SUID EGID RGID SGID PID COMMAND
$ sudo ps -o euid,ruid,suid,egid,rgid,sgid,pid,comm -p 3177
EUID RUID SUID EGID RGID SGID PID COMMAND
1000 1000 1000 1000 1000 103 3177 ssh-agent
================================
Although the binary has the SGID bit set, the process seems to belong to
myself (uid/gid 1000), as it probably dropped ssh-group permissions after
start. But the PID is not visible in /proc and I cannot "find" it:
================================
$ pgrep ssh-agent; echo $?
1
$ pkill ssh-agent; echo $?
1
$ kill 3177; echo $?
0
================================
Because I knew the PID, I could terminate it of course. Is this expected
behaviour? Shouldn't my own processes be visible to myself, even with
/proc mounted with the hidepid=2 option?
Christian.
--
BOFH excuse #412:
Radial Telemetry Infiltration
Christian Kujau <[email protected]> writes:
> Hi,
>
> I was wondering why I cannot see processes that were started from SGID
> programs:
I don't have a clue why anyone would want to hide processes, and make
their own lives more difficult.
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.
Of course if you don't like the silly behavior you can always disable
it.
Eric
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 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. But still, I wonder if this is
intended behaviour.
> Of course if you don't like the silly behavior you can always disable
> it.
:-)
C.
--
BOFH excuse #412:
Radial Telemetry Infiltration
Christian Kujau <[email protected]> writes:
> On Sun, 8 Sep 2013 at 23:42, Eric W. Biederman wrote:
>> 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. But still, I wonder if this is
> intended behaviour.
Well it is acting as desgined so I assume it is intended.
Beyond that shrug.
Eric
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
Vasiliy Kulikov <[email protected]> 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.
Thanks,
Christian.
Christian Kujau <[email protected]> wrote:
>Vasiliy Kulikov <[email protected]>
>"pgrep sgid-program" returned nothing but "kill pics off stiff program"
Gaah, that should read "kill pid-of-sgid-program", sorry.
C.
On Sun, Sep 15, 2013 at 01:58 -0700, Christian Kujau wrote:
> Vasiliy Kulikov <[email protected]> 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