Updated from Linux LTS 3.10.21 to 3.10.22
This commit is contained in:
@@ -291,13 +291,24 @@ Default value is "/sbin/hotplug".
|
||||
kptr_restrict:
|
||||
|
||||
This toggle indicates whether restrictions are placed on
|
||||
exposing kernel addresses via /proc and other interfaces. When
|
||||
kptr_restrict is set to (0), there are no restrictions. When
|
||||
kptr_restrict is set to (1), the default, kernel pointers
|
||||
printed using the %pK format specifier will be replaced with 0's
|
||||
unless the user has CAP_SYSLOG. When kptr_restrict is set to
|
||||
(2), kernel pointers printed using %pK will be replaced with 0's
|
||||
regardless of privileges.
|
||||
exposing kernel addresses via /proc and other interfaces.
|
||||
|
||||
When kptr_restrict is set to (0), the default, there are no restrictions.
|
||||
|
||||
When kptr_restrict is set to (1), kernel pointers printed using the %pK
|
||||
format specifier will be replaced with 0's unless the user has CAP_SYSLOG
|
||||
and effective user and group ids are equal to the real ids. This is
|
||||
because %pK checks are done at read() time rather than open() time, so
|
||||
if permissions are elevated between the open() and the read() (e.g via
|
||||
a setuid binary) then %pK will not leak kernel pointers to unprivileged
|
||||
users. Note, this is a temporary solution only. The correct long-term
|
||||
solution is to do the permission checks at open() time. Consider removing
|
||||
world read permissions from files that use %pK, and using dmesg_restrict
|
||||
to protect against uses of %pK in dmesg(8) if leaking kernel pointer
|
||||
values to unprivileged users is a concern.
|
||||
|
||||
When kptr_restrict is set to (2), kernel pointers printed using
|
||||
%pK will be replaced with 0's regardless of privileges.
|
||||
|
||||
==============================================================
|
||||
|
||||
|
||||
Reference in New Issue
Block a user