Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. 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#34323 - [procps-ng:]sysctl.conf should enable kptr_restrict by default to harden against kernel exploits

Attached to Project: Arch Linux
Opened by hqet4 (hqet4) - Friday, 15 March 2013, 14:33 GMT
Last edited by Gaetan Bisson (vesath) - Thursday, 21 March 2013, 00:41 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Enabling kernel.kptr_restrict will hide kernel symbol addresses in /proc/kallsyms from regular users, making it more difficult for kernel exploits to resolve addresses/symbols dynamically.

This will not help that much on a precompiled ARCH kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but for people compiling their own kernel, this can help mitigating local root exploits...

This task depends upon

Closed by  Gaetan Bisson (vesath)
Thursday, 21 March 2013, 00:41 GMT
Reason for closing:  Upstream
Comment by Gaetan Bisson (vesath) - Sunday, 17 March 2013, 23:43 GMT
I personally despise security through obscurity, so I am strongly against adding that to /etc/sysctl.conf; the cheap sense of security this brings to your system is simply not worth anything.

If you feel otherwise (and are compiling your own kernel, obviously), feel free to use the /etc/sysctl.d directory.
Comment by hqet4 (hqet4) - Wednesday, 20 March 2013, 18:28 GMT
  • Field changed: Percent Complete (100% → 0%)
I'm sorry but I have to disagree. This isn't security through obscurity but simply a mitigation technique that can make kernel exploitation harder in some cases.
By your reasoning, any mitigation technique, like ASLR or NX, should be disabled because it merely makes exploitation harder without fixing the bugs, but (security) bugs in software will always exist and can't always be fixed in a timely manner. So even if exploit mitigation techniques like this one are rarely perfect or always effective, this isn't a sufficient reason to dismiss them.
You say that people compiling their own kernel should enable this option themselves, but you have to know that most of them won't do it, either because they don't have the expertise to know such an option exists or don't understand the security benefits they could gain by enabling it.
In the end, it's also the distro's responsability to ship with sane values enabled by default...
Comment by Jan de Groot (JGC) - Wednesday, 20 March 2013, 18:30 GMT
When this request was made, I googled for possible downsides. So far the only tool that breaks by enabling this is perf, which needs access to kernel symbol addresses to work, but as you can run perf as root only, I don't see a big problem with that.

Other distributions are enabling this by default also, so I don't think it's bad to enable this.
Comment by Gaetan Bisson (vesath) - Thursday, 21 March 2013, 00:35 GMT
The current situation is the sanest: as you said yourself, it is pointless to hide kallsyms for a precompiled kernel, so we leave kernel.kptr_restrict to its default value and let /proc/kallsyms available to whatever programs can make use of it (even if there are only a few).

Deviating from upstream default values goes against our core principles, and is particularly bad when this brings no benefit to our packages.

When you compile your kernel with non-stock configuration, you are expected to update related configuration files yourself too. This is a basic rule which, in fact, applies to all packages. We are simply not going to ship home-made configurations that try to guess what people who recompile their packages might do or want.
Comment by Gaetan Bisson (vesath) - Thursday, 21 March 2013, 00:41 GMT
I also want to comment specifically on hqet4's sentence: "people compiling their own kernel should enable this option themselves, but you have to know that most of them won't do it, either because they don't have the expertise to know such an option exists or don't understand the security benefits"

This is not Ubuntu. People who recompile their own kernel should really know what they are doing. We have no duty to protect people who are ignorant yet modify core parts of their systems. Besides, in the worst-case scenario, they would not be at any more risk than stock kernel users.

Loading...