On Fri, Jul 27, 2018 at 08:04:28PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 27, 2018 at 03:05:43PM -0700, Sandeep Patil wrote:
> > On Fri, Jul 27, 2018 at 04:21:14PM -0400, Theodore Y. Ts'o wrote:
> > > On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > > > That said, I would
On Fri, Jul 27, 2018 at 08:04:28PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 27, 2018 at 03:05:43PM -0700, Sandeep Patil wrote:
> > On Fri, Jul 27, 2018 at 04:21:14PM -0400, Theodore Y. Ts'o wrote:
> > > On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > > > That said, I would
On Fri, Jul 27, 2018 at 03:05:43PM -0700, Sandeep Patil wrote:
> On Fri, Jul 27, 2018 at 04:21:14PM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > > That said, I would assume that
> > > other Android utilities are using other debugfs files
On Fri, Jul 27, 2018 at 03:05:43PM -0700, Sandeep Patil wrote:
> On Fri, Jul 27, 2018 at 04:21:14PM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > > That said, I would assume that
> > > other Android utilities are using other debugfs files
On Fri, Jul 27, 2018 at 04:21:14PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > That said, I would assume that
> > other Android utilities are using other debugfs files for system
> > status and such.
As of today, I think a lot of
On Fri, Jul 27, 2018 at 04:21:14PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > That said, I would assume that
> > other Android utilities are using other debugfs files for system
> > status and such.
As of today, I think a lot of
On Fri, 27 Jul 2018 16:21:14 -0400
"Theodore Y. Ts'o" wrote:
> On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > That said, I would assume that
> > other Android utilities are using other debugfs files for system
> > status and such.
>
> Yeah, I know we probably have lost
On Fri, 27 Jul 2018 16:21:14 -0400
"Theodore Y. Ts'o" wrote:
> On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> > That said, I would assume that
> > other Android utilities are using other debugfs files for system
> > status and such.
>
> Yeah, I know we probably have lost
On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> That said, I would assume that
> other Android utilities are using other debugfs files for system
> status and such.
Yeah, I know we probably have lost the "debugfs is only for debugging
and has no place in a production system"
On Fri, Jul 27, 2018 at 04:11:03PM -0400, Steven Rostedt wrote:
> That said, I would assume that
> other Android utilities are using other debugfs files for system
> status and such.
Yeah, I know we probably have lost the "debugfs is only for debugging
and has no place in a production system"
On Fri, 27 Jul 2018 15:54:16 -0400
"Theodore Y. Ts'o" wrote:
> More generally, stupid question, but does Android *really* need to
> have debugfs mounted? And if so, can we figure out what facilities
> that are needed and can we find some other way of meeting those
> requirements?
I do know
On Fri, 27 Jul 2018 15:54:16 -0400
"Theodore Y. Ts'o" wrote:
> More generally, stupid question, but does Android *really* need to
> have debugfs mounted? And if so, can we figure out what facilities
> that are needed and can we find some other way of meeting those
> requirements?
I do know
More generally, stupid question, but does Android *really* need to
have debugfs mounted? And if so, can we figure out what facilities
that are needed and can we find some other way of meeting those
requirements?
- Ted
More generally, stupid question, but does Android *really* need to
have debugfs mounted? And if so, can we figure out what facilities
that are needed and can we find some other way of meeting those
requirements?
- Ted
+cc jeffv
On Fri, Jul 27, 2018 at 8:47 PM Jann Horn wrote:
>
> On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn wrote:
> >
> > Any system can chose to change the permissions of a sysfs node, default,
> > DAC (and MAC) is just layers of multi-level security (or lack thereof). As
> > well
+cc jeffv
On Fri, Jul 27, 2018 at 8:47 PM Jann Horn wrote:
>
> On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn wrote:
> >
> > Any system can chose to change the permissions of a sysfs node, default,
> > DAC (and MAC) is just layers of multi-level security (or lack thereof). As
> > well
On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn wrote:
>
> Any system can chose to change the permissions of a sysfs node, default, DAC
> (and MAC) is just layers of multi-level security (or lack thereof). As well
> intentioned as a default DAC is in the kernel, leaking kernel addresses is
>
On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn wrote:
>
> Any system can chose to change the permissions of a sysfs node, default, DAC
> (and MAC) is just layers of multi-level security (or lack thereof). As well
> intentioned as a default DAC is in the kernel, leaking kernel addresses is
>
Any system can chose to change the permissions of a sysfs node, default,
DAC (and MAC) is just layers of multi-level security (or lack thereof). As
well intentioned as a default DAC is in the kernel, leaking kernel
addresses is still an attack surface that we want to close tightly.
For instance
Any system can chose to change the permissions of a sysfs node, default,
DAC (and MAC) is just layers of multi-level security (or lack thereof). As
well intentioned as a default DAC is in the kernel, leaking kernel
addresses is still an attack surface that we want to close tightly.
For instance
On Fri, 27 Jul 2018 11:13:51 -0700
Nick Desaulniers wrote:
> I found the internal bug report (reported Jan '17, you'll have to
> forgive me if my memory of the issue is hazy, or if the fix used at
> the time wasn't perfect), which was reported against the Nexus 6.
> >From the report, it was
On Fri, 27 Jul 2018 11:13:51 -0700
Nick Desaulniers wrote:
> I found the internal bug report (reported Jan '17, you'll have to
> forgive me if my memory of the issue is hazy, or if the fix used at
> the time wasn't perfect), which was reported against the Nexus 6.
> >From the report, it was
On Fri, Jul 27, 2018 at 6:47 AM Steven Rostedt wrote:
>
> On Fri, 27 Jul 2018 15:40:32 +0200
> Jann Horn wrote:
>
> > > > But the code doesn't go to dmesg. It's only available
> > > > via /sys/kernel/debug/tracing/printk_formats which is only available
> > > > via root. Nobody else has access to
On Fri, Jul 27, 2018 at 6:47 AM Steven Rostedt wrote:
>
> On Fri, 27 Jul 2018 15:40:32 +0200
> Jann Horn wrote:
>
> > > > But the code doesn't go to dmesg. It's only available
> > > > via /sys/kernel/debug/tracing/printk_formats which is only available
> > > > via root. Nobody else has access to
On Fri, 27 Jul 2018 15:40:32 +0200
Jann Horn wrote:
> > > But the code doesn't go to dmesg. It's only available
> > > via /sys/kernel/debug/tracing/printk_formats which is only available
> > > via root. Nobody else has access to that directory.
> > >
> > > -- Steve
> >
> > I think the point
On Fri, 27 Jul 2018 15:40:32 +0200
Jann Horn wrote:
> > > But the code doesn't go to dmesg. It's only available
> > > via /sys/kernel/debug/tracing/printk_formats which is only available
> > > via root. Nobody else has access to that directory.
> > >
> > > -- Steve
> >
> > I think the point
On Fri, Jul 27, 2018 at 2:07 PM Jordan Glover
wrote:
>
> On July 27, 2018 12:15 AM, Steven Rostedt wrote:
>
> > On Thu, 26 Jul 2018 09:52:11 -0700
> > Nick Desaulniers ndesaulni...@google.com wrote:
> >
> > > See the section "Kernel addresses" in
> > > Documentation/security/self-protection.
On Fri, Jul 27, 2018 at 2:07 PM Jordan Glover
wrote:
>
> On July 27, 2018 12:15 AM, Steven Rostedt wrote:
>
> > On Thu, 26 Jul 2018 09:52:11 -0700
> > Nick Desaulniers ndesaulni...@google.com wrote:
> >
> > > See the section "Kernel addresses" in
> > > Documentation/security/self-protection.
On July 27, 2018 12:15 AM, Steven Rostedt wrote:
> On Thu, 26 Jul 2018 09:52:11 -0700
> Nick Desaulniers ndesaulni...@google.com wrote:
>
> > See the section "Kernel addresses" in
> > Documentation/security/self-protection. IIRC, the issue is that a
> > process may have CAP_SYSLOG but not
On July 27, 2018 12:15 AM, Steven Rostedt wrote:
> On Thu, 26 Jul 2018 09:52:11 -0700
> Nick Desaulniers ndesaulni...@google.com wrote:
>
> > See the section "Kernel addresses" in
> > Documentation/security/self-protection. IIRC, the issue is that a
> > process may have CAP_SYSLOG but not
On Thu, 26 Jul 2018 09:52:11 -0700
Nick Desaulniers wrote:
> See the section "Kernel addresses" in
> Documentation/security/self-protection. IIRC, the issue is that a
> process may have CAP_SYSLOG but not necessarily CAP_SYS_ADMIN (so it
> can read dmesg, but not necessarily issue a sysctl to
On Thu, 26 Jul 2018 09:52:11 -0700
Nick Desaulniers wrote:
> See the section "Kernel addresses" in
> Documentation/security/self-protection. IIRC, the issue is that a
> process may have CAP_SYSLOG but not necessarily CAP_SYS_ADMIN (so it
> can read dmesg, but not necessarily issue a sysctl to
On Thu, Jul 26, 2018 at 9:59 AM Nick Desaulniers
wrote:
>
> On Thu, Jul 26, 2018 at 9:37 AM Steven Rostedt wrote:
> >
> > On Thu, 26 Jul 2018 09:32:07 -0700
> > Nick Desaulniers wrote:
> >
> > > On Thu, Jul 26, 2018 at 8:22 AM Steven Rostedt
> > > wrote:
> > > >
> > > > On Thu, 26 Jul 2018
On Thu, Jul 26, 2018 at 9:59 AM Nick Desaulniers
wrote:
>
> On Thu, Jul 26, 2018 at 9:37 AM Steven Rostedt wrote:
> >
> > On Thu, 26 Jul 2018 09:32:07 -0700
> > Nick Desaulniers wrote:
> >
> > > On Thu, Jul 26, 2018 at 8:22 AM Steven Rostedt
> > > wrote:
> > > >
> > > > On Thu, 26 Jul 2018
On Thu, Jul 26, 2018 at 9:37 AM Steven Rostedt wrote:
>
> On Thu, 26 Jul 2018 09:32:07 -0700
> Nick Desaulniers wrote:
>
> > On Thu, Jul 26, 2018 at 8:22 AM Steven Rostedt wrote:
> > >
> > > On Thu, 26 Jul 2018 08:14:08 -0700
> > > Mark Salyzyn wrote:
> > >
> > > > Thank you Steve, much
On Thu, Jul 26, 2018 at 9:37 AM Steven Rostedt wrote:
>
> On Thu, 26 Jul 2018 09:32:07 -0700
> Nick Desaulniers wrote:
>
> > On Thu, Jul 26, 2018 at 8:22 AM Steven Rostedt wrote:
> > >
> > > On Thu, 26 Jul 2018 08:14:08 -0700
> > > Mark Salyzyn wrote:
> > >
> > > > Thank you Steve, much
On Thu, Jul 26, 2018 at 8:32 AM Greg KH wrote:
>
> On Thu, Jul 26, 2018 at 08:14:08AM -0700, Mark Salyzyn wrote:
> > On 07/25/2018 06:07 PM, Steven Rostedt wrote:
> > > On Wed, 25 Jul 2018 13:22:36 -0700
> > > Mark Salyzyn wrote:
> > >
> > > > From: Nick Desaulniers
> > > >
> > > > Switch from
On Thu, Jul 26, 2018 at 8:32 AM Greg KH wrote:
>
> On Thu, Jul 26, 2018 at 08:14:08AM -0700, Mark Salyzyn wrote:
> > On 07/25/2018 06:07 PM, Steven Rostedt wrote:
> > > On Wed, 25 Jul 2018 13:22:36 -0700
> > > Mark Salyzyn wrote:
> > >
> > > > From: Nick Desaulniers
> > > >
> > > > Switch from
On Thu, 26 Jul 2018 09:32:07 -0700
Nick Desaulniers wrote:
> On Thu, Jul 26, 2018 at 8:22 AM Steven Rostedt wrote:
> >
> > On Thu, 26 Jul 2018 08:14:08 -0700
> > Mark Salyzyn wrote:
> >
> > > Thank you Steve, much appreciated feedback, I have asked the security
> > > developers to keep this
On Thu, 26 Jul 2018 09:32:07 -0700
Nick Desaulniers wrote:
> On Thu, Jul 26, 2018 at 8:22 AM Steven Rostedt wrote:
> >
> > On Thu, 26 Jul 2018 08:14:08 -0700
> > Mark Salyzyn wrote:
> >
> > > Thank you Steve, much appreciated feedback, I have asked the security
> > > developers to keep this
On Thu, Jul 26, 2018 at 8:22 AM Steven Rostedt wrote:
>
> On Thu, 26 Jul 2018 08:14:08 -0700
> Mark Salyzyn wrote:
>
> > Thank you Steve, much appreciated feedback, I have asked the security
> > developers to keep this in mind and come up with a correct fix.
> >
> > The correct fix that meets
On Thu, Jul 26, 2018 at 8:22 AM Steven Rostedt wrote:
>
> On Thu, 26 Jul 2018 08:14:08 -0700
> Mark Salyzyn wrote:
>
> > Thank you Steve, much appreciated feedback, I have asked the security
> > developers to keep this in mind and come up with a correct fix.
> >
> > The correct fix that meets
On Thu, Jul 26, 2018 at 08:14:08AM -0700, Mark Salyzyn wrote:
> On 07/25/2018 06:07 PM, Steven Rostedt wrote:
> > On Wed, 25 Jul 2018 13:22:36 -0700
> > Mark Salyzyn wrote:
> >
> > > From: Nick Desaulniers
> > >
> > > Switch from 0x%lx to 0x%pK to print the kernel addresses.
> > >
> > >
On Thu, Jul 26, 2018 at 08:14:08AM -0700, Mark Salyzyn wrote:
> On 07/25/2018 06:07 PM, Steven Rostedt wrote:
> > On Wed, 25 Jul 2018 13:22:36 -0700
> > Mark Salyzyn wrote:
> >
> > > From: Nick Desaulniers
> > >
> > > Switch from 0x%lx to 0x%pK to print the kernel addresses.
> > >
> > >
On Thu, 26 Jul 2018 08:14:08 -0700
Mark Salyzyn wrote:
> Thank you Steve, much appreciated feedback, I have asked the security
> developers to keep this in mind and come up with a correct fix.
>
> The correct fix that meets your guidelines would _not_ be suitable for
> stable due to the
On Thu, 26 Jul 2018 08:14:08 -0700
Mark Salyzyn wrote:
> Thank you Steve, much appreciated feedback, I have asked the security
> developers to keep this in mind and come up with a correct fix.
>
> The correct fix that meets your guidelines would _not_ be suitable for
> stable due to the
On 07/25/2018 06:07 PM, Steven Rostedt wrote:
On Wed, 25 Jul 2018 13:22:36 -0700
Mark Salyzyn wrote:
From: Nick Desaulniers
Switch from 0x%lx to 0x%pK to print the kernel addresses.
Fixes: CVE-2017-0630
Wait This breaks perf and trace-cmd! They require this to be able
to print various
On 07/25/2018 06:07 PM, Steven Rostedt wrote:
On Wed, 25 Jul 2018 13:22:36 -0700
Mark Salyzyn wrote:
From: Nick Desaulniers
Switch from 0x%lx to 0x%pK to print the kernel addresses.
Fixes: CVE-2017-0630
Wait This breaks perf and trace-cmd! They require this to be able
to print various
On Wed, 25 Jul 2018 13:22:36 -0700
Mark Salyzyn wrote:
> From: Nick Desaulniers
>
> Switch from 0x%lx to 0x%pK to print the kernel addresses.
>
> Fixes: CVE-2017-0630
Wait This breaks perf and trace-cmd! They require this to be able
to print various strings in trace events. This file is
On Wed, 25 Jul 2018 13:22:36 -0700
Mark Salyzyn wrote:
> From: Nick Desaulniers
>
> Switch from 0x%lx to 0x%pK to print the kernel addresses.
>
> Fixes: CVE-2017-0630
Wait This breaks perf and trace-cmd! They require this to be able
to print various strings in trace events. This file is
On Wed, Jul 25, 2018 at 1:23 PM Mark Salyzyn wrote:
>
> From: Nick Desaulniers
> Signed-off-by: Mark Salyzyn
>
Thanks for sending. You should take credit/authorship, and add my
Reviewed-by: Nick Desaulniers
--
Thanks,
~Nick Desaulniers
On Wed, Jul 25, 2018 at 1:23 PM Mark Salyzyn wrote:
>
> From: Nick Desaulniers
> Signed-off-by: Mark Salyzyn
>
Thanks for sending. You should take credit/authorship, and add my
Reviewed-by: Nick Desaulniers
--
Thanks,
~Nick Desaulniers
From: Nick Desaulniers
Switch from 0x%lx to 0x%pK to print the kernel addresses.
Fixes: CVE-2017-0630
Signed-off-by: Mark Salyzyn
Cc: Nick Desaulniers
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc:
Cc: # 3.18, 4.4, 4.9, 4.14
Cc:
---
kernel/trace/trace_printk.c | 2 +-
1 file changed, 1
From: Nick Desaulniers
Switch from 0x%lx to 0x%pK to print the kernel addresses.
Fixes: CVE-2017-0630
Signed-off-by: Mark Salyzyn
Cc: Nick Desaulniers
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc:
Cc: # 3.18, 4.4, 4.9, 4.14
Cc:
---
kernel/trace/trace_printk.c | 2 +-
1 file changed, 1
54 matches
Mail list logo