Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug

[Askar Safin <safinaskar@gmail.com>]

Willy Tarreau <w@1wt.eu>:
> +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