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
- 112 LFX Mentorship
- 112 LFX Mentorship: Linux Kernel
- 604 Linux Foundation IT Professional Programs
- 315 Cloud Engineer IT Professional Program
- 139 Advanced Cloud Engineer IT Professional Program
- 52 DevOps Engineer IT Professional Program
- 67 Cloud Native Developer IT Professional Program
- 4 Express Training Courses
- 4 Express Courses - Discussion Forum
- 5.3K Training Courses
- 17 LFC110 Class Forum - Discontinued
- 8 LFC131 Class Forum
- 30 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
- 127 LFD232 Class Forum - Discontinued
- LFD233 Class Forum
- LFD237 Class Forum
- 22 LFD254 Class Forum
- 643 LFD259 Class Forum
- 107 LFD272 Class Forum
- 1 LFD272-JP クラス フォーラム
- 4 LFD273 Class Forum
- 1 LFS101 Class Forum
- LFS112 Class Forum
- LFS116 Class Forum
- LFS118 Class Forum
- LFS142 Class Forum
- LFS144 Class Forum
- 2 LFS145 Class Forum
- LFS146 Class Forum
- LFS151 Class Forum
- LFS157 Class Forum
- LFS158 Class Forum
- LFS162 Class Forum
- LFS166 Class Forum
- LFS167 Class Forum
- 28 LFS200 Class Forum
- 735 LFS201 Class Forum - Discontinued
- 1 LFS201-JP クラス フォーラム
- 13 LFS203 Class Forum
- 98 LFS207 Class Forum
- 299 LFS211 Class Forum
- 54 LFS216 Class Forum
- 47 LFS241 Class Forum
- 41 LFS242 Class Forum
- 36 LFS243 Class Forum
- 12 LFS244 Class Forum
- LFS245 Class Forum
- 41 LFS250 Class Forum
- 1 LFS250-JP クラス フォーラム
- LFS251 Class Forum
- 141 LFS253 Class Forum
- LFS254 Class Forum
- LFS255 Class Forum
- 2 LFS256 Class Forum
- LFS257 Class Forum
- 1.2K LFS258 Class Forum
- 9 LFS258-JP クラス フォーラム
- 109 LFS260 Class Forum
- 144 LFS261 Class Forum
- 39 LFS262 Class Forum
- 82 LFS263 Class Forum - Discontinued
- 15 LFS264 Class Forum - Discontinued
- 11 LFS266 Class Forum - Discontinued
- 20 LFS267 Class Forum
- 18 LFS268 Class Forum
- 26 LFS269 Class Forum
- 198 LFS272 Class Forum
- 1 LFS272-JP クラス フォーラム
- LFS274 Class Forum
- 3 LFS281 Class Forum
- 254 LFW211 Class Forum
- 173 LFW212 Class Forum
- 9 SKF100 Class Forum
- SKF200 Class Forum
- 781 Hardware
- 198 Drivers
- 68 I/O Devices
- 37 Monitors
- 95 Multimedia
- 174 Networking
- 87 Printers & Scanners
- 83 Storage
- 742 Linux Distributions
- 80 Debian
- 66 Fedora
- 15 Linux Mint
- 13 Mageia
- 23 openSUSE
- 143 Red Hat Enterprise
- 31 Slackware
- 13 SUSE Enterprise
- 347 Ubuntu
- 450 Linux System Administration
- 31 Cloud Computing
- 69 Command Line/Scripting
- Github systems admin projects
- 89 Linux Security
- 76 Network Management
- 101 System Management
- 46 Web Management
- 51 Mobile Computing
- 18 Android
- 23 Development
- 1.2K New to Linux
- 1K Getting Started with Linux
- 355 Off Topic
- 109 Introductions
- 167 Small Talk
- 18 Study Material
- 504 Programming and Development
- 283 Kernel Development
- 203 Software Development
- 844 Software
- 210 Applications
- 180 Command Line
- 3 Compiling/Installing
- 107 Games
- 308 Installation
- 51 All In Program
- 51 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)