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 a
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 for
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 information
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 the
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" batt
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 that
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 intentione
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
> still
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
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 possi
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 was
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. IIRC
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 necessa
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 ch
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 08:
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 appreci
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 0
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 i
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 you
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.
> > >
> > > Fixes:
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 invasi
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 r
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
26 matches
Mail list logo