Documentation/translations/sp_SP/process/embargoed-hardware-issues.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2 .. include:: ../disclaimer-sp.rst
   3
   4 :Original: Documentation/process/embargoed-hardware-issues.rst
   5 :Translator: Avadhut Naik <avadhut.naik@amd.com>
   6
   7 Problemas de hardware embargados
   8 ================================
   9
  10 Alcance
  11 -------
  12
  13 Los problemas de hardware que resultan en problemas de seguridad son una
  14 categoría diferente de errores de seguridad que los errores de software
  15 puro que solo afectan al kernel de Linux.
  16
  17 Los problemas de hardware como Meltdown, Spectre, L1TF, etc. deben
  18 tratarse de manera diferente porque usualmente afectan a todos los
  19 sistemas operativos (“OS”) y, por lo tanto, necesitan coordinación entre
  20 vendedores diferentes de OS, distribuciones, vendedores de hardware y
  21 otras partes. Para algunos de los problemas, las mitigaciones de software
  22 pueden depender de actualizaciones de microcódigo o firmware, los cuales
  23 necesitan una coordinación adicional.
  24
  25 .. _Contacto:
  26
  27 Contacto
  28 --------
  29
  30 El equipo de seguridad de hardware del kernel de Linux es separado del
  31 equipo regular de seguridad del kernel de Linux.
  32
  33 El equipo solo maneja la coordinación de los problemas de seguridad de
  34 hardware embargados. Los informes de errores de seguridad de software puro
  35 en el kernel de Linux no son manejados por este equipo y el "reportero"
  36 (quien informa del error) será guiado a contactar el equipo de seguridad
  37 del kernel de Linux (:doc:`errores de seguridad <security-bugs>`) en su
  38 lugar.
  39
  40 El equipo puede contactar por correo electrónico en
  41 <hardware-security@kernel.org>. Esta es una lista privada de oficiales de
  42 seguridad que lo ayudarán a coordinar un problema de acuerdo con nuestro
  43 proceso documentado.
  44
  45 La lista esta encriptada y el correo electrónico a la lista puede ser
  46 enviado por PGP o S/MIME encriptado y debe estar firmado con la llave de
  47 PGP del reportero o el certificado de S/MIME. La llave de PGP y el
  48 certificado de S/MIME de la lista están disponibles en las siguientes
  49 URLs:
  50
  51   - PGP: https://www.kernel.org/static/files/hardware-security.asc
  52   - S/MIME: https://www.kernel.org/static/files/hardware-security.crt
  53
  54 Si bien los problemas de seguridad del hardware a menudo son manejados por
  55 el vendedor de hardware afectado, damos la bienvenida al contacto de
  56 investigadores o individuos que hayan identificado una posible falla de
  57 hardware.
  58
  59 Oficiales de seguridad de hardware
  60 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  61
  62 El equipo actual de oficiales de seguridad de hardware:
  63
  64   - Linus Torvalds (Linux Foundation Fellow)
  65   - Greg Kroah-Hartman (Linux Foundation Fellow)
  66   - Thomas Gleixner (Linux Foundation Fellow)
  67
  68 Operación de listas de correo
  69 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  70
  71 Las listas de correo encriptadas que se utilizan en nuestro proceso están
  72 alojados en la infraestructura de IT de la Fundación Linux. Al proporcionar
  73 este servicio, los miembros del personal de operaciones de IT de la
  74 Fundación Linux técnicamente tienen la capacidad de acceder a la
  75 información embargada, pero están obligados a la confidencialidad por su
  76 contrato de trabajo. El personal de IT de la Fundación Linux también es
  77 responsable para operar y administrar el resto de la infraestructura de
  78 kernel.org.
  79
  80 El actual director de infraestructura de proyecto de IT de la Fundación
  81 Linux es Konstantin Ryabitsev.
  82
  83 Acuerdos de no divulgación
  84 --------------------------
  85
  86 El equipo de seguridad de hardware del kernel de Linux no es un organismo
  87 formal y, por lo tanto, no puede firmar cualquier acuerdo de no
  88 divulgación. La comunidad del kernel es consciente de la naturaleza
  89 delicada de tales problemas y ofrece un Memorando de Entendimiento en su
  90 lugar.
  91
  92 Memorando de Entendimiento
  93 --------------------------
  94
  95 La comunidad del kernel de Linux tiene una comprensión profunda del
  96 requisito de mantener los problemas de seguridad de hardware bajo embargo
  97 para la coordinación entre diferentes vendedores de OS, distribuidores,
  98 vendedores de hardware y otras partes.
  99
 100 La comunidad del kernel de Linux ha manejado con éxito los problemas de
 101 seguridad del hardware en el pasado y tiene los mecanismos necesarios para
 102 permitir el desarrollo compatible con la comunidad bajo restricciones de
 103 embargo.
 104
 105 La comunidad del kernel de Linux tiene un equipo de seguridad de hardware
 106 dedicado para el contacto inicial, el cual supervisa el proceso de manejo
 107 de tales problemas bajo las reglas de embargo.
 108
 109 El equipo de seguridad de hardware identifica a los desarrolladores
 110 (expertos en dominio) que formarán el equipo de respuesta inicial para un
 111 problema en particular. El equipo de respuesta inicial puede involucrar
 112 más desarrolladores (expertos en dominio) para abordar el problema de la
 113 mejor manera técnica.
 114
 115 Todos los desarrolladores involucrados se comprometen a adherirse a las
 116 reglas del embargo y a mantener confidencial la información recibida. La
 117 violación de la promesa conducirá a la exclusión inmediata del problema
 118 actual y la eliminación de todas las listas de correo relacionadas.
 119 Además, el equipo de seguridad de hardware también excluirá al
 120 delincuente de problemas futuros. El impacto de esta consecuencia es un
 121 elemento de disuasión altamente efectivo en nuestra comunidad. En caso de
 122 que ocurra una violación, el equipo de seguridad de hardware informará a
 123 las partes involucradas inmediatamente. Si usted o alguien tiene
 124 conocimiento de una posible violación, por favor, infórmelo inmediatamente
 125 a los oficiales de seguridad de hardware.
 126
 127 Proceso
 128 ^^^^^^^
 129
 130 Debido a la naturaleza distribuida globalmente del desarrollo del kernel
 131 de Linux, las reuniones cara a cara hacen imposible abordar los
 132 problemas de seguridad del hardware. Las conferencias telefónicas son
 133 difíciles de coordinar debido a las zonas horarias y otros factores y
 134 solo deben usarse cuando sea absolutamente necesario. El correo
 135 electrónico encriptado ha demostrado ser el método de comunicación más
 136 efectivo y seguro para estos tipos de problemas.
 137
 138 Inicio de la divulgación
 139 """"""""""""""""""""""""
 140
 141 La divulgación comienza contactado al equipo de seguridad de hardware del
 142 kernel de Linux por correo electrónico. Este contacto inicial debe
 143 contener una descripción del problema y una lista de cualquier hardware
 144 afectado conocido. Si su organización fabrica o distribuye el hardware
 145 afectado, le animamos a considerar también que otro hardware podría estar
 146 afectado.
 147
 148 El equipo de seguridad de hardware proporcionará una lista de correo
 149 encriptada específica para el incidente que se utilizará para la discusión
 150 inicial con el reportero, la divulgación adicional y la coordinación.
 151
 152 El equipo de seguridad de hardware proporcionará a la parte reveladora una
 153 lista de desarrolladores (expertos de dominios) a quienes se debe informar
 154 inicialmente sobre el problema después de confirmar con los
 155 desarrolladores que se adherirán a este Memorando de Entendimiento y al
 156 proceso documentado. Estos desarrolladores forman el equipo de respuesta
 157 inicial y serán responsables de manejar el problema después del contacto
 158 inicial. El equipo de seguridad de hardware apoyará al equipo de
 159 respuesta, pero no necesariamente involucrandose en el proceso de desarrollo
 160 de mitigación.
 161
 162 Si bien los desarrolladores individuales pueden estar cubiertos por un
 163 acuerdo de no divulgación a través de su empleador, no pueden firmar
 164 acuerdos individuales de no divulgación en su papel de desarrolladores
 165 del kernel de Linux. Sin embargo, aceptarán adherirse a este proceso
 166 documentado y al Memorando de Entendimiento.
 167
 168 La parte reveladora debe proporcionar una lista de contactos para todas
 169 las demás entidades ya que han sido, o deberían ser, informadas sobre el
 170 problema. Esto sirve para varios propósitos:
 171
 172  - La lista de entidades divulgadas permite la comunicación en toda la
 173    industria, por ejemplo, otros vendedores de OS, vendedores de HW, etc.
 174
 175  - Las entidades divulgadas pueden ser contactadas para nombrar a expertos
 176    que deben participar en el desarrollo de la mitigación.
 177
 178  - Si un experto que se requiere para manejar un problema es empleado por
 179    una entidad cotizada o un miembro de una entidad cotizada, los equipos
 180    de respuesta pueden solicitar la divulgación de ese experto a esa
 181    entidad. Esto asegura que el experto también forme parte del equipo de
 182    respuesta de la entidad.
 183
 184 Divulgación
 185 """""""""""
 186
 187 La parte reveladora proporcionará información detallada al equipo de
 188 respuesta inicial a través de la lista de correo encriptada especifica.
 189
 190 Según nuestra experiencia, la documentación técnica de estos problemas
 191 suele ser un punto de partida suficiente y es mejor hacer aclaraciones
 192 técnicas adicionales a través del correo electrónico.
 193
 194 Desarrollo de la mitigación
 195 """""""""""""""""""""""""""
 196
 197 El equipo de respuesta inicial configura una lista de correo encriptada o
 198 reutiliza una existente si es apropiada.
 199
 200 El uso de una lista de correo está cerca del proceso normal de desarrollo
 201 de Linux y se ha utilizado con éxito en el desarrollo de mitigación para
 202 varios problemas de seguridad de hardware en el pasado.
 203
 204 La lista de correo funciona en la misma manera que el desarrollo normal de
 205 Linux. Los parches se publican, discuten y revisan y, si se acuerda, se
 206 aplican a un repositorio git no público al que solo pueden acceder los
 207 desarrolladores participantes a través de una conexión segura. El
 208 repositorio contiene la rama principal de desarrollo en comparación con
 209 el kernel principal y las ramas backport para versiones estables del
 210 kernel según sea necesario.
 211
 212 El equipo de respuesta inicial identificará a más expertos de la
 213 comunidad de desarrolladores del kernel de Linux según sea necesario. La
 214 incorporación de expertos puede ocurrir en cualquier momento del proceso
 215 de desarrollo y debe manejarse de manera oportuna.
 216
 217 Si un experto es empleado por o es miembro de una entidad en la lista de
 218 divulgación proporcionada por la parte reveladora, entonces se solicitará
 219 la participación de la entidad pertinente.
 220
 221 Si no es así, entonces se informará a la parte reveladora sobre la
 222 participación de los expertos. Los expertos están cubiertos por el
 223 Memorando de Entendimiento y se solicita a la parte reveladora que
 224 reconozca la participación. En caso de que la parte reveladora tenga una
 225 razón convincente para objetar, entonces esta objeción debe plantearse
 226 dentro de los cinco días laborables y resolverse con el equipo de
 227 incidente inmediatamente. Si la parte reveladora no reacciona dentro de
 228 los cinco días laborables, esto se toma como un reconocimiento silencioso.
 229
 230 Después del reconocimiento o la resolución de una objeción, el experto es
 231 revelado por el equipo de incidente y se incorpora al proceso de
 232 desarrollo.
 233
 234 Lanzamiento coordinado
 235 """"""""""""""""""""""
 236
 237 Las partes involucradas negociarán la fecha y la hora en la que termina el
 238 embargo. En ese momento, las mitigaciones preparadas se integran en los
 239 árboles de kernel relevantes y se publican.
 240
 241 Si bien entendemos que los problemas de seguridad del hardware requieren
 242 un tiempo de embargo coordinado, el tiempo de embargo debe limitarse al
 243 tiempo mínimo que se requiere para que todas las partes involucradas
 244 desarrollen, prueben y preparen las mitigaciones. Extender el tiempo de
 245 embargo artificialmente para cumplir con las fechas de discusión de la
 246 conferencia u otras razones no técnicas está creando más trabajo y carga
 247 para los desarrolladores y los equipos de respuesta involucrados, ya que
 248 los parches necesitan mantenerse actualizados para seguir el desarrollo en
 249 curso del kernel upstream, lo cual podría crear cambios conflictivos.
 250
 251 Asignación de CVE
 252 """""""""""""""""
 253
 254 Ni el equipo de seguridad de hardware ni el equipo de respuesta inicial
 255 asignan CVEs, ni se requieren para el proceso de desarrollo. Si los CVEs
 256 son proporcionados por la parte reveladora, pueden usarse con fines de
 257 documentación.
 258
 259 Embajadores del proceso
 260 -----------------------
 261
 262 Para obtener asistencia con este proceso, hemos establecido embajadores
 263 en varias organizaciones, que pueden responder preguntas o proporcionar
 264 orientación sobre el proceso de reporte y el manejo posterior. Los
 265 embajadores no están involucrados en la divulgación de un problema en
 266 particular, a menos que lo solicite un equipo de respuesta o una parte
 267 revelada involucrada. La lista de embajadores actuales:
 268
 269   ============= ========================================================
 270   AMD           Tom Lendacky <thomas.lendacky@amd.com>
 271   Ampere        Darren Hart <darren@os.amperecomputing.com>
 272   ARM           Catalin Marinas <catalin.marinas@arm.com>
 273   IBM Power     Anton Blanchard <anton@linux.ibm.com>
 274   IBM Z         Christian Borntraeger <borntraeger@de.ibm.com>
 275   Intel         Tony Luck <tony.luck@intel.com>
 276   Qualcomm      Trilok Soni <tsoni@codeaurora.org>
 277   Samsung       Javier González <javier.gonz@samsung.com>
 278
 279   Microsoft     James Morris <jamorris@linux.microsoft.com>
 280   Xen           Andrew Cooper <andrew.cooper3@citrix.com>
 281
 282   Canonical     John Johansen <john.johansen@canonical.com>
 283   Debian        Ben Hutchings <ben@decadent.org.uk>
 284   Oracle        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
 285   Red Hat       Josh Poimboeuf <jpoimboe@redhat.com>
 286   SUSE          Jiri Kosina <jkosina@suse.cz>
 287
 288   Google        Kees Cook <keescook@chromium.org>
 289
 290   LLVM          Nick Desaulniers <ndesaulniers@google.com>
 291   ============= ========================================================
 292
 293 Si quiere que su organización se añada a la lista de embajadores, por
 294 favor póngase en contacto con el equipo de seguridad de hardware. El
 295 embajador nominado tiene que entender y apoyar nuestro proceso
 296 completamente y está idealmente bien conectado en la comunidad del kernel
 297 de Linux.
 298
 299 Listas de correo encriptadas
 300 ----------------------------
 301
 302 Usamos listas de correo encriptadas para la comunicación. El principio de
 303 funcionamiento de estas listas es que el correo electrónico enviado a la
 304 lista se encripta con la llave PGP de la lista o con el certificado S/MIME
 305 de la lista. El software de lista de correo descifra el correo electrónico
 306 y lo vuelve a encriptar individualmente para cada suscriptor con la llave
 307 PGP del suscriptor o el certificado S/MIME. Los detalles sobre el software
 308 de la lista de correo y la configuración que se usa para asegurar la
 309 seguridad de las listas y la protección de los datos se pueden encontrar
 310 aquí: https://korg.wiki.kernel.org/userdoc/remail.
 311
 312 Llaves de lista
 313 ^^^^^^^^^^^^^^^
 314
 315 Para el contacto inicial, consulte :ref:`Contacto`. Para las listas de
 316 correo especificas de incidentes, la llave y el certificado S/MIME se
 317 envían a los suscriptores por correo electrónico desde la lista
 318 especifica.
 319
 320 Suscripción a listas específicas de incidentes
 321 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 322
 323 La suscripción es manejada por los equipos de respuesta. Las partes
 324 reveladas que quieren participar en la comunicación envían una lista de
 325 suscriptores potenciales al equipo de respuesta para que el equipo de
 326 respuesta pueda validar las solicitudes de suscripción.
 327
 328 Cada suscriptor necesita enviar una solicitud de suscripción al equipo de
 329 respuesta por correo electrónico. El correo electrónico debe estar firmado
 330 con la llave PGP del suscriptor o el certificado S/MIME. Si se usa una
 331 llave PGP, debe estar disponible desde un servidor de llave publica y esta
 332 idealmente conectada a la red de confianza PGP del kernel de Linux. Véase
 333 también: https://www.kernel.org/signature.html.
 334
 335 El equipo de respuesta verifica que la solicitud del suscriptor sea válida
 336 y añade al suscriptor a la lista. Después de la suscripción, el suscriptor
 337 recibirá un correo electrónico de la lista que está firmado con la llave
 338 PGP de la lista o el certificado S/MIME de la lista. El cliente de correo
 339 electrónico del suscriptor puede extraer la llave PGP o el certificado
 340 S/MIME de la firma, de modo que el suscriptor pueda enviar correo
 341 electrónico encriptado a la lista.