[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez25zgjTQRux_rk1fn2DUVthtK31dRU9cxE+55pBGmYjXQ@mail.gmail.com>
Date: Fri, 27 Jul 2018 20:47:27 +0200
From: Jann Horn <jannh@...gle.com>
To: salyzyn@...gle.com
Cc: Steven Rostedt <rostedt@...dmis.org>, Nick Desaulniers <ndesaulniers@...gle.com>,
Golden_Miller83@...tonmail.ch, Greg KH <greg@...ah.com>,
Kees Cook <keescook@...gle.com>, salyzyn@...roid.com,
kernel list <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, kernel-team@...roid.com,
stable@...r.kernel.org,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH] tracing: do not leak kernel addresses
On Fri, Jul 27, 2018 at 8:41 PM Mark Salyzyn <salyzyn@...gle.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@...dmis.org> wrote:
>>
>> On Fri, 27 Jul 2018 11:13:51 -0700
>> Nick Desaulniers <ndesaulniers@...gle.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@...roid.com.
>>
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
