security-bugs.rst

  1.. SPDX-License-Identifier: GPL-2.0
  2.. include:: ../disclaimer-sp.rst
  3
  4:Original: Documentation/process/security-bugs.rst
  5:Translator: Avadhut Naik <avadhut.naik@amd.com>
  6
  7Errores de seguridad
  8====================
  9
 10Los desarrolladores del kernel de Linux se toman la seguridad muy en
 11serio. Como tal, nos gustaría saber cuándo se encuentra un error de
 12seguridad para que pueda ser corregido y divulgado lo más rápido posible.
 13Por favor, informe sobre los errores de seguridad al equipo de seguridad
 14del kernel de Linux.
 15
 16Contacto
 17--------
 18
 19El equipo de seguridad del kernel de Linux puede ser contactado por correo
 20electrónico en <security@kernel.org>. Esta es una lista privada de
 21oficiales de seguridad que ayudarán a verificar el informe del error y
 22desarrollarán y publicarán una corrección. Si ya tiene una corrección, por
 23favor, inclúyala con su informe, ya que eso puede acelerar considerablemente
 24el proceso. Es posible que el equipo de seguridad traiga ayuda adicional
 25de mantenedores del área para comprender y corregir la vulnerabilidad de
 26seguridad.
 27
 28Como ocurre con cualquier error, cuanta más información se proporcione,
 29más fácil será diagnosticarlo y corregirlo. Por favor, revise el
 30procedimiento descrito en 'Documentation/admin-guide/reporting-issues.rst'
 31si no tiene claro que información es útil. Cualquier código de explotación
 32es muy útil y no será divulgado sin el consentimiento del "reportero" (el
 33que envia el error) a menos que ya se haya hecho público.
 34
 35Por favor, envíe correos electrónicos en texto plano sin archivos
 36adjuntos cuando sea posible. Es mucho más difícil tener una discusión
 37citada en contexto sobre un tema complejo si todos los detalles están
 38ocultos en archivos adjuntos. Piense en ello como un
 39:doc:`envío de parche regular <submitting-patches>` (incluso si no tiene
 40un parche todavía) describa el problema y el impacto, enumere los pasos
 41de reproducción, y sígalo con una solución propuesta, todo en texto plano.
 42
 43
 44Divulgación e información embargada
 45-----------------------------------
 46
 47La lista de seguridad no es un canal de divulgación. Para eso, ver
 48Coordinación debajo. Una vez que se ha desarrollado una solución robusta,
 49comienza el proceso de lanzamiento. Las soluciones para errores conocidos
 50públicamente se lanzan inmediatamente.
 51
 52Aunque nuestra preferencia es lanzar soluciones para errores no divulgados
 53públicamente tan pronto como estén disponibles, esto puede postponerse a
 54petición del reportero o una parte afectada por hasta 7 días calendario
 55desde el inicio del proceso de lanzamiento, con una extensión excepcional
 56a 14 días de calendario si se acuerda que la criticalidad del error requiere
 57más tiempo. La única razón válida para aplazar la publicación de una
 58solución es para acomodar la logística de QA y los despliegues a gran
 59escala que requieren coordinación de lanzamiento.
 60
 61Si bien la información embargada puede compartirse con personas de
 62confianza para desarrollar una solución, dicha información no se publicará
 63junto con la solución o en cualquier otro canal de divulgación sin el
 64permiso del reportero. Esto incluye, pero no se limita al informe original
 65del error y las discusiones de seguimiento (si las hay), exploits,
 66información sobre CVE o la identidad del reportero.
 67
 68En otras palabras, nuestro único interés es solucionar los errores. Toda
 69otra información presentada a la lista de seguridad y cualquier discusión
 70de seguimiento del informe se tratan confidencialmente incluso después de
 71que se haya levantado el embargo, en perpetuidad.
 72
 73Coordinación con otros grupos
 74-----------------------------
 75
 76El equipo de seguridad del kernel recomienda encarecidamente que los
 77reporteros de posibles problemas de seguridad NUNCA contacten la lista
 78de correo “linux-distros” hasta DESPUES de discutirlo con el equipo de
 79seguridad del kernel. No Cc: ambas listas a la vez. Puede ponerse en
 80contacto con la lista de correo linux-distros después de que se haya
 81acordado una solución y comprenda completamente los requisitos que al
 82hacerlo le impondrá a usted y la comunidad del kernel.
 83
 84Las diferentes listas tienen diferentes objetivos y las reglas de
 85linux-distros no contribuyen en realidad a solucionar ningún problema de
 86seguridad potencial.
 87
 88Asignación de CVE
 89-----------------
 90
 91El equipo de seguridad no asigna CVEs, ni los requerimos para informes o
 92correcciones, ya que esto puede complicar innecesariamente el proceso y
 93puede retrasar el manejo de errores. Si un reportero desea que se le
 94asigne un identificador CVE, debe buscar uno por sí mismo, por ejemplo,
 95poniéndose en contacto directamente con MITRE. Sin embargo, en ningún
 96caso se retrasará la inclusión de un parche para esperar a que llegue un
 97identificador CVE.
 98
 99Acuerdos de no divulgación
100--------------------------
101
102El equipo de seguridad del kernel de Linux no es un organismo formal y,
103por lo tanto, no puede firmar cualquier acuerdo de no divulgación.