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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ