Lab 8.4
Sorry that I'm querying a lot.
On this exercise I'm finding the addresses are revealed as just 0s whether I have kernel.kptr_restrict on or off. Why am I not getting the desired result (did this on CentOS)?
[mo79uk@localhost ~]$ sudo sysctl kernel.kptr_restrict=1
kernel.kptr_restrict = 1
[mo79uk@localhost ~]$ head /proc/kallsyms
0000000000000000 A irq_stack_union
0000000000000000 A __per_cpu_start
0000000000000000 A init_tss
0000000000000000 A __per_cpu_user_mapped_start
0000000000000000 A exception_stacks
0000000000000000 A gdt_page
0000000000000000 A kaiser_scratch
0000000000000000 A spec_ctrl_pcp
0000000000000000 A kaiser_enabled_pcp
0000000000000000 A cpu_debug_store
[mo79uk@localhost ~]$ sudo sysctl kernel.kptr_restrict=0
kernel.kptr_restrict = 0
[mo79uk@localhost ~]$ head /proc/kallsyms
0000000000000000 A irq_stack_union
0000000000000000 A __per_cpu_start
0000000000000000 A init_tss
0000000000000000 A __per_cpu_user_mapped_start
0000000000000000 A exception_stacks
0000000000000000 A gdt_page
0000000000000000 A kaiser_scratch
0000000000000000 A spec_ctrl_pcp
0000000000000000 A kaiser_enabled_pcp
0000000000000000 A cpu_debug_store
There's also a typo in the solution:
$ head /proc/ka0000000000000000 A irq_stack_union
Thanks again if you can help!
Comments
-
Thanks for letting us know abut the typo, it is a formatting error.
As for the real question, yes, your observation is correct. it is intended that the regular user should see the addresses if the kptr_restrict is 0 and the addresses hidden if kptr_restrict is not 0.Something has changed, I will looking this.
Thanks Lee
0 -
I found it, there was an update to the restrictions to allow a regular user to view the addresses, see below ...
from kallsyms.c
/*
* We show kallsyms information even to normal users if we've enabled
* kernel profiling and are explicitly not paranoid (so kptr_restrict
* is clear, and sysctl_perf_event_paranoid isn't set).
*
* Otherwise, require CAP_SYSLOG (assuming kptr_restrict isn't set to
* block even that).
/
int kallsyms_show_value(void)
{
switch (kptr_restrict) {
case 0:
if (kallsyms_for_perf())
return 1;
/ fallthrough /
case 1:
if (has_capability_noaudit(current, CAP_SYSLOG))
return 1;
/ fallthrough */
default:
return 0;
}
}So we need to set the following:
sysctl -w kernel.kptr_restrict=0
sysctl -w kernel.perf_event_paranoid=1
Then a regular user will be able to see the addresses in /proc/kallsyms
Or the executable can have the capability CAP_SYSLOG applied.
This update will be in the next release.
Thank you for pointing this issue out.
Lee0
Categories
- All Categories
- 64 LFX Mentorship
- 117 LFX Mentorship: Linux Kernel
- 618 Linux Foundation IT Professional Programs
- 322 Cloud Engineer IT Professional Program
- 141 Advanced Cloud Engineer IT Professional Program
- 56 DevOps Engineer IT Professional Program
- 67 Cloud Native Developer IT Professional Program
- 6 Express Training Courses
- 6 Express Courses - Discussion Forum
- 2.4K Training Courses
- 19 LFC110 Class Forum - Discontinued
- 9 LFC131 Class Forum
- 31 LFD102 Class Forum
- 178 LFD103 Class Forum
- LFD110 Class Forum
- 24 LFD121 Class Forum
- LFD133 Class Forum
- 2 LFD137 Class Forum
- 62 LFD201 Class Forum
- 2 LFD210 Class Forum
- 1 LFD210-CN Class Forum
- 1 LFD213 Class Forum - Discontinued
- 128 LFD232 Class Forum - Discontinued
- LFD233 Class Forum
- LFD237 Class Forum
- 23 LFD254 Class Forum
- 660 LFD259 Class Forum
- 108 LFD272 Class Forum
- 1 LFD272-JP クラス フォーラム
- 4 LFD273 Class Forum
- 1 LFS101 Class Forum
- LFS116 Class Forum
- 2 LFS145 Class Forum
- LFS151 Class Forum
- LFS158 Class Forum
- LFS167 Class Forum
- 28 LFS200 Class Forum
- 740 LFS201 Class Forum - Discontinued
- 1 LFS201-JP クラス フォーラム
- 13 LFS203 Class Forum
- 98 LFS207 Class Forum
- 301 LFS211 Class Forum
- 54 LFS216 Class Forum
- 47 LFS241 Class Forum
- 41 LFS242 Class Forum
- 38 LFS243 Class Forum
- 12 LFS244 Class Forum
- LFS245 Class Forum
- 41 LFS250 Class Forum
- 1 LFS250-JP クラス フォーラム
- LFS251 Class Forum
- 143 LFS253 Class Forum
- LFS254 Class Forum
- LFS255 Class Forum
- 2 LFS256 Class Forum
- LFS257 Class Forum
- 1.2K LFS258 Class Forum
- 10 LFS258-JP クラス フォーラム
- 109 LFS260 Class Forum
- 147 LFS261 Class Forum
- 39 LFS262 Class Forum
- 83 LFS263 Class Forum - Discontinued
- 15 LFS264 Class Forum - Discontinued
- 11 LFS266 Class Forum - Discontinued
- 21 LFS267 Class Forum
- 18 LFS268 Class Forum
- 26 LFS269 Class Forum
- 204 LFS272 Class Forum
- 1 LFS272-JP クラス フォーラム
- LFS274 Class Forum
- 3 LFS281 Class Forum
- 258 LFW211 Class Forum
- 179 LFW212 Class Forum
- 9 SKF100 Class Forum
- SKF200 Class Forum
- 908 Hardware
- 221 Drivers
- 74 I/O Devices
- 44 Monitors
- 116 Multimedia
- 210 Networking
- 102 Printers & Scanners
- 86 Storage
- 765 Linux Distributions
- 88 Debian
- 66 Fedora
- 15 Linux Mint
- 13 Mageia
- 24 openSUSE
- 144 Red Hat Enterprise
- 33 Slackware
- 13 SUSE Enterprise
- 357 Ubuntu
- 484 Linux System Administration
- 40 Cloud Computing
- 71 Command Line/Scripting
- Github systems admin projects
- 95 Linux Security
- 80 Network Management
- 108 System Management
- 52 Web Management
- 75 Mobile Computing
- 25 Android
- 35 Development
- 1.2K New to Linux
- 1.1K Getting Started with Linux
- 544 Off Topic
- 131 Introductions
- 223 Small Talk
- 22 Study Material
- 836 Programming and Development
- 285 Kernel Development
- 517 Software Development
- 975 Software
- 261 Applications
- 185 Command Line
- 3 Compiling/Installing
- 119 Games
- 318 Installation
- 65 All In Program
- 65 All In Forum
Upcoming Training
-
August 20, 2018
Kubernetes Administration (LFS458)
-
August 20, 2018
Linux System Administration (LFS301)
-
August 27, 2018
Open Source Virtualization (LFS462)
-
August 27, 2018
Linux Kernel Debugging and Security (LFD440)