|
@@ -290,13 +290,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.
|
|
|
|
|
|
==============================================================
|
|
|
|