linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jann Horn <jannh@google.com>
To: salyzyn@google.com
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Golden_Miller83@protonmail.ch, Greg KH <greg@kroah.com>,
	Kees Cook <keescook@google.com>,
	salyzyn@android.com, kernel list <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	kernel-team@android.com, stable@vger.kernel.org,
	Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH] tracing: do not leak kernel addresses
Date: Fri, 27 Jul 2018 20:47:27 +0200	[thread overview]
Message-ID: <CAG48ez25zgjTQRux_rk1fn2DUVthtK31dRU9cxE+55pBGmYjXQ@mail.gmail.com> (raw)
In-Reply-To: <CAMx4XWv3OazvURuN1XU2+5C5tNDzPuTniMn_T=XTA4P8_uwS_A@mail.gmail.com>

On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn <salyzyn@google.com> 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 an attack surface that we want to close tightly.
>
> For instance on Android:
>
>      chmod 0755 /sys/kernel/debug/tracing
>
> is in the common init.rc file ...
>
> If DAC has been adjusted at runtime to permit access to the node, I would think that if the caller does not have all the credentials/capabilities, we do want the addresses to be abstracted by the kernel.

If you adjust the access controls on debugfs to permit things that
aren't possible upstream, you may have to add new access controls to
ensure that that doesn't lead to security issues. And, in fact, you
did:

walleye:/ # ls -laZ /sys/kernel/debug
total 0
drwxr-xr-x 100 root root u:object_r:debugfs:s0             0 2018-07-27 18:08 .
drwxr-xr-x  19 root root u:object_r:sysfs:s0               0 1970-06-04 10:30 ..
[...]
drwxr-xr-x   6 root root u:object_r:debugfs_tracing:s0     0
1970-01-01 01:00 tracing
drwxr-xr-x   2 root root u:object_r:debugfs:s0             0
1970-01-01 01:00 tsens
drwxr-xr-x   2 root root u:object_r:debugfs:s0             0
1970-01-01 01:00 tzdbg
drwxr-xr-x   4 root root u:object_r:debugfs_ufs:s0         0
1970-01-01 01:00 ufshcd0
drwxr-xr-x   2 root root u:object_r:debugfs:s0             0
1970-01-01 01:00 usb
drwxr-xr-x   2 root root u:object_r:debugfs:s0             0
1970-01-01 01:00 usb-pdphy
drwxr-xr-x   2 root root u:object_r:debugfs:s0             0
1970-01-01 01:00 usb_diag
drwxr-xr-x   2 root root u:object_r:debugfs:s0             0
1970-01-01 01:00 vmem
-r--r--r--   1 root root u:object_r:debugfs:s0             0
1970-01-01 01:00 wakeup_sources
drwxr-xr-x   2 root root u:object_r:debugfs:s0             0
2018-07-27 18:07 wcd_spi
drwxr-xr-x   2 root root u:object_r:debugfs:s0             0
2018-07-27 18:07 wdsp0
drwxr-xr-x   2 root root u:object_r:debugfs_wlan:s0        0
2018-07-27 18:07 wlan0
drwxr-xr-x   3 root root u:object_r:debugfs:s0             0
2018-07-27 18:07 wlan_qdf

Stuff in the debugfs mount is labeled as "debugfs", with a few
exceptions. And the SELinux policy locks down access to debugfs:

public/domain.te:neverallow { domain -init -vendor_init -system_server
-dumpstate } debugfs:file no_rw_file_perms;

> On Fri, Jul 27, 2018 at 11:31 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>
>> On Fri, 27 Jul 2018 11:13:51 -0700
>> Nick Desaulniers <ndesaulniers@google.com> 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 possible to `cat
>> > /sys/kernel/debug/tracing/printk_formats` without being root, which I
>> > can't do on my workstations much more modern kernel (Nexus 6 was
>> > 3.10).  So I guess the question is what governs access to files below
>> > /sys/kernel/debug, and why was it missing from those kernels?  I
>> > assume some check was added, but either not backported to 3.10 stable
>> > (or more likely not pulled in to Nexus 6's kernel through stable;
>> > Android is now in a much better place for that kind of issue).
>>
>> As of commit 82aceae4f0d4 ("debugfs: more tightly restrict default
>> mount mode") /sys/kernel/debug has been default mounted as 0700 (root
>> only). But that was introduced in 3.7. Not sure why your 3.10 kernel
>> didn't have that. Perhaps there's another commit that fixed
>> permissions not being inherited?
>>
>> -- Steve
>>
>> --
>> You received this message because you are subscribed to the Google Groups "kernel-team" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>>
>

  parent reply	other threads:[~2018-07-27 18:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25 20:22 [PATCH] tracing: do not leak kernel addresses Mark Salyzyn
2018-07-25 21:14 ` Nick Desaulniers
2018-07-26  1:07 ` Steven Rostedt
2018-07-26 15:14   ` Mark Salyzyn
2018-07-26 15:22     ` Steven Rostedt
2018-07-26 16:32       ` Nick Desaulniers
2018-07-26 16:37         ` Steven Rostedt
2018-07-26 16:59           ` Nick Desaulniers
2018-07-26 21:56             ` Nick Desaulniers
2018-07-26 15:31     ` Greg KH
2018-07-26 16:52       ` Nick Desaulniers
2018-07-26 22:15         ` Steven Rostedt
2018-07-27 12:07           ` Jordan Glover
2018-07-27 13:40             ` Jann Horn
2018-07-27 13:47               ` Steven Rostedt
2018-07-27 18:13                 ` Nick Desaulniers
2018-07-27 18:31                   ` Steven Rostedt
     [not found]                     ` <CAMx4XWv3OazvURuN1XU2+5C5tNDzPuTniMn_T=XTA4P8_uwS_A@mail.gmail.com>
2018-07-27 18:47                       ` Jann Horn [this message]
2018-07-27 18:58                         ` Jann Horn
2018-07-27 19:54                           ` Theodore Y. Ts'o
2018-07-27 20:11                             ` Steven Rostedt
2018-07-27 20:21                               ` Theodore Y. Ts'o
2018-07-27 20:53                                 ` Steven Rostedt
2018-07-27 22:05                                 ` Sandeep Patil
2018-07-28  0:04                                   ` Theodore Y. Ts'o
2018-07-30 14:35                                     ` Sandeep Patil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAG48ez25zgjTQRux_rk1fn2DUVthtK31dRU9cxE+55pBGmYjXQ@mail.gmail.com \
    --to=jannh@google.com \
    --cc=Golden_Miller83@protonmail.ch \
    --cc=greg@kroah.com \
    --cc=keescook@google.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=ndesaulniers@google.com \
    --cc=rostedt@goodmis.org \
    --cc=salyzyn@android.com \
    --cc=salyzyn@google.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).