Willy Tarreau <[email protected]>: > +in a way that allows multiple local users to get a fair share of the > available
Your "security-bugs.rst" says that we should consult "threat-model.rst" to determine whether a bug should be sent to secret mailing list. And "threat-model.rst" says that kernel gives everyone "fair share" of resources. This can be interpreted so: if scheduler is not fair enough, then this is security bug and should be reported to secret mailing list. I don't think this is what you meant. > +When hardware fails to maintain its specified isolation (e.g., CPU bugs, > +side-channels, hardware response to unexpected inputs), the kernel will > usually > +attempt to implement reasonable mitigations. These are best-effort measures > +intended to reduce the attack surface or elevate the cost of an attack within > +the limits of the hardware's facilities; they do not constitute a > +kernel-provided safety guarantee. "best-effort measures" and "they do not constitute a kernel-provided safety guarantee" can be interpreted so: if someone finds yet another Meltdown-like side-channel CPU bug, then this is not security bug, and should be reported openly. I don't think this is what you meant. > + affect the system's availability (shutdown, reboot, panic, hang, or > making > + the system unresponsive via unbounded resource exhaustion). So if unprivileged process can crash system, then this is security bug? Also I'm not sure "unbounded resource exhaustion" is correct here. As well as I understand, by default kernel and distros don't set any memory limits or limits for number of processes for unprivileged processes, so unprivileged process can easily cause resource exhaustion by allocating a lot of memory or by fork bomb. So, I think you should instead say that unprivileged process, which has memory limit (and other limits) set using cgroups, should not be able to cause resource exhaustion. > +are designed to be accessible to regular local users with a low risk (e.g. > +kernel logs via ``/proc/kmsg``), some would expose enough information to /proc/kmsg has rights "-r--------", so I think there is error here. --------------- Finally, I have questions: - If unprivileged user created process, which is impossible to kill by privileged process, is this security bug? - If unprivileged user prevents privileged user from suspending system, is this security bug? -- Askar Safin
