* Re: /proc/timer_list leaks the real pids of the associated processes
[not found] <CAJwLwmYQt2ae_Y-TDXhPGsX5im29ATwwKmg3FtUC=6HjrzH4HA@mail.gmail.com>
@ 2017-02-03 23:44 ` Kees Cook
2017-02-07 22:48 ` Thomas Gleixner
0 siblings, 1 reply; 6+ messages in thread
From: Kees Cook @ 2017-02-03 23:44 UTC (permalink / raw)
To: Xing Gao
Cc: LKML, Thomas Gleixner, kernel-hardening, Jessica Frazelle,
Eric W. Biederman
On Fri, Feb 3, 2017 at 2:29 PM, Xing Gao <xgao01@email.wm.edu> wrote:
> Dear Thomas and Kees,
>
> I posted a bug report on bugzilla, and John asked me to send it the lkml.
>
> Here is the link, https://bugzilla.kernel.org/show_bug.cgi?id=193921
>
> Please cc to me when you reply this email.
>
> And please check the information below.
>
> The pseudo file /proc/timer_list leaks the real pids of the associated
> processes.
>
> The function print_timer(kernel/time/timer_list.c) displays
> timer->start_pid, which is set inside the function
> __timer_stats_timer_set_start_info (kernel/time/timer.c). This is the real
> pid, rather than the pid in the pid namespace. If the user within a
> container retrieves the content of /proc/timer_list, this file will leak the
> real pid of the associated process.
I feel like this has been pointed out before, but I can't find the
email about it. Regardless, yeah, this looks true:
SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
#11: <0000000000000000>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
Seems like this should be made namespace aware... (and why is this
file needed at all? Seems like it should live in debugfs not proc).
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: /proc/timer_list leaks the real pids of the associated processes
2017-02-03 23:44 ` /proc/timer_list leaks the real pids of the associated processes Kees Cook
@ 2017-02-07 22:48 ` Thomas Gleixner
2017-02-07 22:56 ` Jessica Frazelle
2017-02-07 23:24 ` Kees Cook
0 siblings, 2 replies; 6+ messages in thread
From: Thomas Gleixner @ 2017-02-07 22:48 UTC (permalink / raw)
To: Kees Cook
Cc: Xing Gao, LKML, kernel-hardening, Jessica Frazelle, Eric W. Biederman
On Fri, 3 Feb 2017, Kees Cook wrote:
> On Fri, Feb 3, 2017 at 2:29 PM, Xing Gao <xgao01@email.wm.edu> wrote:
> > Dear Thomas and Kees,
> >
> > I posted a bug report on bugzilla, and John asked me to send it the lkml.
> >
> > Here is the link, https://bugzilla.kernel.org/show_bug.cgi?id=193921
> >
> > Please cc to me when you reply this email.
> >
> > And please check the information below.
> >
> > The pseudo file /proc/timer_list leaks the real pids of the associated
> > processes.
> >
> > The function print_timer(kernel/time/timer_list.c) displays
> > timer->start_pid, which is set inside the function
> > __timer_stats_timer_set_start_info (kernel/time/timer.c). This is the real
> > pid, rather than the pid in the pid namespace. If the user within a
> > container retrieves the content of /proc/timer_list, this file will leak the
> > real pid of the associated process.
>
> I feel like this has been pointed out before, but I can't find the
> email about it. Regardless, yeah, this looks true:
>
> SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
>
> #11: <0000000000000000>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
>
> Seems like this should be made namespace aware... (and why is this
> file needed at all? Seems like it should live in debugfs not proc).
I'm fine with that.
The TIMER_STATS stuff should go away completely. If people are interested
in that information they can use the tracer which gives way better
data than that file.
Thanks,
tglx
.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: /proc/timer_list leaks the real pids of the associated processes
2017-02-07 22:48 ` Thomas Gleixner
@ 2017-02-07 22:56 ` Jessica Frazelle
2017-02-08 9:47 ` Thomas Gleixner
2017-02-07 23:24 ` Kees Cook
1 sibling, 1 reply; 6+ messages in thread
From: Jessica Frazelle @ 2017-02-07 22:56 UTC (permalink / raw)
To: Thomas Gleixner, Kees Cook
Cc: Xing Gao, LKML, kernel-hardening, Eric W. Biederman
So I used to use this "feature" as a hack to see if something was
running in a k8s cluster or not because fluentd gives a lot of things
away. Runc basically decided to mask this file so it stopped happening
though. But I think namespace aware is the right decision.
On Tue, Feb 7, 2017 at 2:48 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Fri, 3 Feb 2017, Kees Cook wrote:
>
> > On Fri, Feb 3, 2017 at 2:29 PM, Xing Gao <xgao01@email.wm.edu> wrote:
> > > Dear Thomas and Kees,
> > >
> > > I posted a bug report on bugzilla, and John asked me to send it the lkml.
> > >
> > > Here is the link, https://bugzilla.kernel.org/show_bug.cgi?id=193921
> > >
> > > Please cc to me when you reply this email.
> > >
> > > And please check the information below.
> > >
> > > The pseudo file /proc/timer_list leaks the real pids of the associated
> > > processes.
> > >
> > > The function print_timer(kernel/time/timer_list.c) displays
> > > timer->start_pid, which is set inside the function
> > > __timer_stats_timer_set_start_info (kernel/time/timer.c). This is the real
> > > pid, rather than the pid in the pid namespace. If the user within a
> > > container retrieves the content of /proc/timer_list, this file will leak the
> > > real pid of the associated process.
> >
> > I feel like this has been pointed out before, but I can't find the
> > email about it. Regardless, yeah, this looks true:
> >
> > SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
> >
> > #11: <0000000000000000>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
> >
> > Seems like this should be made namespace aware... (and why is this
> > file needed at all? Seems like it should live in debugfs not proc).
>
> I'm fine with that.
>
> The TIMER_STATS stuff should go away completely. If people are interested
> in that information they can use the tracer which gives way better
> data than that file.
>
> Thanks,
>
> tglx
> .
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: /proc/timer_list leaks the real pids of the associated processes
2017-02-07 22:48 ` Thomas Gleixner
2017-02-07 22:56 ` Jessica Frazelle
@ 2017-02-07 23:24 ` Kees Cook
2017-02-07 23:34 ` Kees Cook
1 sibling, 1 reply; 6+ messages in thread
From: Kees Cook @ 2017-02-07 23:24 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Xing Gao, LKML, kernel-hardening, Jessica Frazelle, Eric W. Biederman
On Tue, Feb 7, 2017 at 2:48 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 3 Feb 2017, Kees Cook wrote:
>
>> On Fri, Feb 3, 2017 at 2:29 PM, Xing Gao <xgao01@email.wm.edu> wrote:
>> > Dear Thomas and Kees,
>> >
>> > I posted a bug report on bugzilla, and John asked me to send it the lkml.
>> >
>> > Here is the link, https://bugzilla.kernel.org/show_bug.cgi?id=193921
>> >
>> > Please cc to me when you reply this email.
>> >
>> > And please check the information below.
>> >
>> > The pseudo file /proc/timer_list leaks the real pids of the associated
>> > processes.
>> >
>> > The function print_timer(kernel/time/timer_list.c) displays
>> > timer->start_pid, which is set inside the function
>> > __timer_stats_timer_set_start_info (kernel/time/timer.c). This is the real
>> > pid, rather than the pid in the pid namespace. If the user within a
>> > container retrieves the content of /proc/timer_list, this file will leak the
>> > real pid of the associated process.
>>
>> I feel like this has been pointed out before, but I can't find the
>> email about it. Regardless, yeah, this looks true:
>>
>> SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
>>
>> #11: <0000000000000000>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
>>
>> Seems like this should be made namespace aware... (and why is this
>> file needed at all? Seems like it should live in debugfs not proc).
>
> I'm fine with that.
>
> The TIMER_STATS stuff should go away completely. If people are interested
> in that information they can use the tracer which gives way better
> data than that file.
As in, entirely remote CONFIG_TIMER_STATS?
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: /proc/timer_list leaks the real pids of the associated processes
2017-02-07 23:24 ` Kees Cook
@ 2017-02-07 23:34 ` Kees Cook
0 siblings, 0 replies; 6+ messages in thread
From: Kees Cook @ 2017-02-07 23:34 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Xing Gao, LKML, kernel-hardening, Jessica Frazelle, Eric W. Biederman
On Tue, Feb 7, 2017 at 3:24 PM, Kees Cook <keescook@google.com> wrote:
> On Tue, Feb 7, 2017 at 2:48 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> On Fri, 3 Feb 2017, Kees Cook wrote:
>>
>>> On Fri, Feb 3, 2017 at 2:29 PM, Xing Gao <xgao01@email.wm.edu> wrote:
>>> > Dear Thomas and Kees,
>>> >
>>> > I posted a bug report on bugzilla, and John asked me to send it the lkml.
>>> >
>>> > Here is the link, https://bugzilla.kernel.org/show_bug.cgi?id=193921
>>> >
>>> > Please cc to me when you reply this email.
>>> >
>>> > And please check the information below.
>>> >
>>> > The pseudo file /proc/timer_list leaks the real pids of the associated
>>> > processes.
>>> >
>>> > The function print_timer(kernel/time/timer_list.c) displays
>>> > timer->start_pid, which is set inside the function
>>> > __timer_stats_timer_set_start_info (kernel/time/timer.c). This is the real
>>> > pid, rather than the pid in the pid namespace. If the user within a
>>> > container retrieves the content of /proc/timer_list, this file will leak the
>>> > real pid of the associated process.
>>>
>>> I feel like this has been pointed out before, but I can't find the
>>> email about it. Regardless, yeah, this looks true:
>>>
>>> SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
>>>
>>> #11: <0000000000000000>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
>>>
>>> Seems like this should be made namespace aware... (and why is this
>>> file needed at all? Seems like it should live in debugfs not proc).
>>
>> I'm fine with that.
>>
>> The TIMER_STATS stuff should go away completely. If people are interested
>> in that information they can use the tracer which gives way better
>> data than that file.
>
> As in, entirely remote CONFIG_TIMER_STATS?
s/remote/remove/
I'll send a patch...
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: /proc/timer_list leaks the real pids of the associated processes
2017-02-07 22:56 ` Jessica Frazelle
@ 2017-02-08 9:47 ` Thomas Gleixner
0 siblings, 0 replies; 6+ messages in thread
From: Thomas Gleixner @ 2017-02-08 9:47 UTC (permalink / raw)
To: Jessica Frazelle
Cc: Kees Cook, Xing Gao, LKML, kernel-hardening, Eric W. Biederman
On Tue, 7 Feb 2017, Jessica Frazelle wrote:
> So I used to use this "feature" as a hack to see if something was
> running in a k8s cluster or not because fluentd gives a lot of things
> away.
That file does not tell you at all whether something is running or not. It
merily tells you that there are timers queued.
> Runc basically decided to mask this file so it stopped happening
> though. But I think namespace aware is the right decision.
Unless you can come up with a real good argument why this is usefull beyond
debugging and crystal ball hackery, it's going to go away.
Thanks,
tglx
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-08 9:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAJwLwmYQt2ae_Y-TDXhPGsX5im29ATwwKmg3FtUC=6HjrzH4HA@mail.gmail.com>
2017-02-03 23:44 ` /proc/timer_list leaks the real pids of the associated processes Kees Cook
2017-02-07 22:48 ` Thomas Gleixner
2017-02-07 22:56 ` Jessica Frazelle
2017-02-08 9:47 ` Thomas Gleixner
2017-02-07 23:24 ` Kees Cook
2017-02-07 23:34 ` Kees Cook
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).