* 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: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
* 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
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
all inboxes | Powered by JetHome®