[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 5 Nov 2015 10:27:32 -0500 (EST)
From: cve-assign@...re.org
To: vdronov@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, pmatouse@...hat.com
Subject: Re: CVE request -- Linux kernel: selinux: rate-limit unrecognized netlink message warnings in selinux_nlmsg_perm()
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> https://bugzilla.redhat.com/show_bug.cgi?id=1278005
> http://article.gmane.org/gmane.linux.kernel.lsm/25958
Our current feeling is that this might be best categorized as a
security enhancement (with no CVE ID) rather than a vulnerability fix.
Is there a documented policy that a privilege boundary is crossed in
all cases where a printk can be triggered by an unprivileged user, or
cases where the number of printk calls is somehow "too many" or the
required circumstances happen "too often"?
We'd like to avoid a situation where a CVE ID is needed every time
that a kernel patch exists that changes a printk to a
pr_warn_ratelimited (regardless of whether the patch is ultimately
added to the stable kernel).
We feel it's more reasonable to have a CVE ID in a case where code is
intended to have the functionality of printing something (with a rate
limit), but the functionality is broken because of an inadvertent
coding error, or because of a divergence between a distribution kernel
and upstream, e.g., something like
https://bugzilla.redhat.com/show_bug.cgi?id=1115545#c5
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bb1dc0bacb8ddd7ba6a5906c678a5a5a110cf695
but where a pr_warn_ratelimited was supposed to alert a system
administrator about an attack.
(Also, 1115545#c5 mentions "I think maybe the reason no one has
noticed is due to the low usage of ratelimiting - from what I counted
there were only a handful of pr_warn_ratelimit calls, and most were in
nfs.")
An example similar to the current one apparently does not have a CVE:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bfc5184b69cf9eeb286137640351c650c27f118a
People have proposed putting pr_warn_ratelimited into the
nfs4_schedule_state_manager function in the
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/nfs/nfs4state.c
file, but that hasn't happened:
https://bugs.launchpad.net/bugs/1423472
http://unix.stackexchange.com/questions/130742/how-to-enable-printk-selectively
discusses configuration options, suggesting that the security
enhancement of putting in a pr_warn_ratelimited is not needed on all
machines.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJWO3RKAAoJEL54rhJi8gl5BCYQAICe0NaiE4jUrQFZRserj52e
Ma6LI9AxvxXREB74jRRLPOV4HEYOnACnAoOk45g61QEE+/9Px28tdQfDTd9Rwi9C
Zf3HX119VIwE9Trv8MZ2H8SzFTSMLsM5Qg4VGxLGkkNJx1G6hqPVPu3dqBA8DLoN
+Kl9WShcXoqhIvlB3PBEqxkzyQnobeU0W0lWbl5bNDvMuf8nFp0GF4ClWDdZWKDs
z+KJQ269iBQAeVI9g+8SwTuXmS3S4FG6H11IY24labutOaEJYv5fgdltNYYuPSBc
ruo4A0pHIT3Q8xSAlLTRx0ZBk3DVaFG4ScQKjTofJIKKNAFmAWqzQzTutahWd584
8iAUaU9WNkuGyUhe5LnnC50+CoAWdmNwgmOdBD2zIRdVtBey5wF3PxncOzHMcI2Q
I5yFcyY+WexnQjkIKqfuHIe7uJacicZ4QGnM/Uk4cBEOXDla2+WSj6PFTfkNqFPd
yKT77vfhP7wFGdiF3FiDo1CUVcj9h057ps8hhDfCtfelmSWgr6gEJv4Ueno0vrAQ
LgK0eH8z7uW3UonEG8W6pXFX9D/js6z0ShMJlyNOB+Fa7LatNDr5GSU5MuUM1FDh
7t1Esi42WoEWZPFKVC5pcyGfKDvnBFWajXDa5bOg42poNogmbcxxVGdjYu0VDx0S
ePT+hfNc9OOcnG4jyJUW
=L5+e
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
