Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#59613 - [linux-headers] Restrict access to System.map/vmlinux

Attached to Project: Arch Linux
Opened by Tommy Schmitt (spinka) - Saturday, 11 August 2018, 10:44 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 12 August 2018, 05:34 GMT
Task Type General Gripe
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

After recent changes in linux package PKGBUILD, the 'System.map'[0] file is reintroduced in '/usr/lib/modules/<kernel_version/build/System.map'.

Access to this file may be sensitive for security and is restricted to '400' on Ubuntu/Debian systems[1].

Arch can do the same thing and use 'chmod 400 System.map' in PKGBUILD.

Similar thing may be done with 'vmlinux' kernel image which is currently available in two places:
(1) /boot/vmlinuz-linux
(2) /usr/lib/modules/<kernel_version/build/vmlinux

I'm not sure what the purpose of (2) is. You may consider removing it or harden access to it as described above.

[0] https://en.wikipedia.org/wiki/System.map
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615029
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Sunday, 12 August 2018, 05:34 GMT
Reason for closing:  Not a bug
Additional comments about closing:  This is completely junk logic, we are not going to make every file on the OS readable only by root because "principle of least privileges" and "Attacker don't have to bother with finding package files over the net"
Comment by Tommy Schmitt (spinka) - Saturday, 11 August 2018, 10:59 GMT
Alternatively 'System.map' may be removed completely as there is '/proc/kallsyms' available which was the reason to get rid of 'System.map' some years ago[0] and the install directory is so unique that no tool would detect it anyway[1].

[0] https://bugs.archlinux.org/task/25247
[1] http://dirac.org/linux/system.map/
Comment by loqs (loqs) - Saturday, 11 August 2018, 12:28 GMT
vmlinuz-linuz is also available in the kernel package itself freely downloadable from any mirror or for older versions from the ALA.
What is to stop someone using a reproducible build to generate System.map? KASLR randomizes the base at boot time.
I am not against removing System.map as redundant but I do not see it as providing any security benefits.
Comment by Tommy Schmitt (spinka) - Saturday, 11 August 2018, 13:12 GMT
@loqs
Yes generic distro files can be downloaded by anyone from mirror thus I didn't marked this as highly important.

There are two things however:
1. Attacker don't have to bother with finding package files over the net as relevant files are stored in host available for anyone :)

2. It hurts everyone building their custom kernel using Arch Linux template who doesn't realise there are sensitive files stored by default.
Comment by loqs (loqs) - Saturday, 11 August 2018, 13:20 GMT
In the custom kernel scenario are you assuming KASLR is disabled or it does not work or what sensitive information are you referring to?
Can you provide proof of concept code for instance that can extract this information and match it to a running kernel?
Edit:
spelling not instead of nto
Comment by Tommy Schmitt (spinka) - Saturday, 11 August 2018, 14:45 GMT
I meant potentially sensitive in some corner cases (i.e. disabled kaslr or whatever). I don't know if System.map values can help to defeat kaslr (find infoleak and calculate the shift).

Again, I agree this doesn't present real security threat for users but I thought it's good to stick with the 'least privilege' principle.

Loading...