Hace 5 años | Por --586391-- a linuxadictos.com
Publicado hace 5 años por --586391-- a linuxadictos.com

Se han identificado tres vulnerabilidades que permiten a un atacante sin privilegios elevar sus privilegios en el sistema y ejecutar el código como root en systemd-journald el cual es el responsable del inicio de sesión en systemd. Las vulnerabilidades se manifiestan en todas las distribuciones que usan systemd, con la excepción de SUSE Linux Enterprise 15, openSUSE Leap 15.0 y Fedora 28/29, en las cuales los componentes de systemd se ensamblan con la inclusión de “-fstack-clash-protection”.

Comentarios

anv

#12 Yo administro unos cuantos servidores Linux y no le he visto ventaja. De hecho, me complica algunos "toqueteos" que antes hacía fácilmente.

meneandro

#14 ¿Cuáles?

anv

#15 pues por ejemplo antes era trivial modificar los scripts que arrancan programas. Eso sin contar con que ahora han metido procesos de parada y arranque en binarios compilados que requerirían recompilar para modificarlos.
Otra cosa molesta es que cuando modificas algo hay que hacer que relea los cambios manualmente porque si no sigue como antes.

meneandro

#16 Ahora sigue siendo trivial. Antes necesitabas saber bash (o cualquier lenguaje de script), ahora necesitas saber son las distintas opciones de configuración para montar las units. La diferencia es que las units te lo dan (casi) todo lo que pudieras necesitar hecho.

Y eso de los procesos de parada y arranque en binarios... los procesos de arranque y parada los defines tú como quieras y quien lo hace al fin y al cabo es la aplicación, systemd sólo da un framework para realizarlo de manera estandarizada y controlada. Aquí las opciones (y si te fijas, systemd no para ni reinicia nada, eres tú quien le dices cómo y de qué forma parar):

ExecStart=: This specifies the full path and the arguments of the command to be executed to start the process. This may only be specified once (except for "oneshot" services). If the path to the command is preceded by a dash "-" character, non-zero exit statuses will be accepted without marking the unit activation as failed.
ExecStartPre=: This can be used to provide additional commands that should be executed before the main process is started. This can be used multiple times. Again, commands must specify a full path and they can be preceded by "-" to indicate that the failure of the command will be tolerated.
ExecStartPost=: This has the same exact qualities as ExecStartPre= except that it specifies commands that will be run after the main process is started.
ExecReload=: This optional directive indicates the command necessary to reload the configuration of the service if available.
ExecStop=: This indicates the command needed to stop the service. If this is not given, the process will be killed immediately when the service is stopped.
ExecStopPost=: This can be used to specify commands to execute following the stop command.
RestartSec=: If automatically restarting the service is enabled, this specifies the amount of time to wait before attempting to restart the service.
Restart=: This indicates the circumstances under which systemd will attempt to automatically restart the service. This can be set to values like "always", "on-success", "on-failure", "on-abnormal", "on-abort", or "on-watchdog". These will trigger a restart according to the way that the service was stopped.
TimeoutSec=: This configures the amount of time that systemd will wait when stopping or stopping the service before marking it as failed or forcefully killing it. You can set separate timeouts with TimeoutStartSec= and TimeoutStopSec= as well.


https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files

Ah, y por cierto, sigues pudiendo usar scripts de inico a la sysVinit si te apetece, systemd es compatible con ellos...

Sobre recargar cuando haces cambios... basta con hacerlo sobre el servicio que te interesa (igual que si haces cambios de configuración en ese servicio, vaya):

https://serverfault.com/questions/700862/do-systemd-unit-files-have-to-be-reloaded-when-modified

anv

#18 Mira, por ejemplo ayer tenía un problema: necesitaba agregarle un LD_LIBRARY_PATH al apache (para que funcionara el módulo de Oracle para PHP). En todas partes decía que era simplemente ponerlo en el /etc/sysconfig/apache. Claro: en un script de arranque "normal" hacia un . /etc/sysconfig/apache, con lo que cualquier variable de entorno que agregaras ahí pasaba a estar en el entorno del apache al arrancar. Pero por lo visto systemd no hace eso así que no me tomaba nada que pusiera ahí.

meneandro

#19 Aquí lo mismo hombre. Con añadir entradas Environment...

[Unit]
Description=My Daemon

[Service]
Environment="FOO=bar baz"
ExecStart=/bin/myforegroundcmd

[Install]
WantedBy=multi-user.target


Si no quieres fijar el valor de la variable de entorno estáticamente (y recargar la unit en caso de modificarla), también puedes cargarla desde un fichero externo:

[Service]
EnvironmentFile=/ruta/al/archivo

D

#14
Debes ser todo un gurú, utilizando servidores Linux en vez de GNU. Linux a palo seco debe ser bastante fuerte.

R

Menuda traducción de mierda. Voto spam, fusilarse un copy paste de Google translate no tiene esfuerzo ninguno.

Vodker

#3 eso no es cierto según el artículo... "Actualmente, las distribuciones de vulnerabilidades aún no están parchadas son de las más populares tales como Debian, Ubuntu, RHEL, Fedora, SUSE, así como sus derivados."
#1 sí, la traducción es una mierda.

D

#1 Si, la traducción es una mierda, pero según mi búsqueda fueron los primeros que lo publicaron en 'castellano'.

R

#8 Tu búsqueda no habrá sido en Google.es no? Porque no veas cómo manipula la realidad de Internet Google, y Duckdugo v aporte el mismo camino aunque no lo parezca de momento.

D

Se les escucha llegar...

...a los pelacables que usan distros hipster con init (que no usa prácticamente nadie en entornos de producción) a explicarnos como systemd es el mal.

R

#2 Hombre, a mi en general Systemd me mola, es un poco mierda porque quiere abarcar muchas cosas a veces (en mi opinión) que por un lado te quita algunos problemas pero te da otros cuando algo no va como esperas o si algún conflicto con algo que tienes tu configurado.

Pero vamos, tampoco te diría que voy a rechazar una distro en entornos de producción porque usa "init", "openrc", "upstart" or "systemd". Aparte, que ahora hay distros ya como RancherOS que reemplazan init por Docker tal cual (https://rancher.com/docs/os/v1.x/en/).

meneandro

#4 Systemd como tal abarca el sistema de arranque, gestión y la inicialización de la parte de usuario en el sistema. Otra cosa es que haya muchos proyectos que se alojan bajo el paraguas de systemd (por aprovechar el framework creado y reutilizar código y recursos, lo cual es la forma correcta de hacer las cosas), pero al final son muchos binarios distintos que hacen cosas muy concretas y que pueden ser sustituíbles por otros si se desarrolla algo que realice mejor la misma función.

anv

#2 Realmente uso systemd porque "es lo que hay" pero no termina de gustarme. Me parece una complicación extra que no aporta nada notable.

meneandro

#6 A nivel de usuario seguro que no, a nivel de administración de sistemas aporta muchas cosas.

el_loro

#2 Systemd es el mal. Distro con OpenRC. De nada.

D

No se dice GNU/Linux, se dice Linux.

anv

Obviamente hay que aclarar que antes de que se publicara esto las distribuciones han actualizado para corregirlo.

pkreuzt

#3 Algunas aún no. En Debian aún estan explotables las dos primeras vulnerabilidades, la tercera al parecer se corrigió en el código sin que nadie se diese cuenta hace tiempo.

https://security-tracker.debian.org/tracker/CVE-2018-16864

https://security-tracker.debian.org/tracker/CVE-2018-16865

https://security-tracker.debian.org/tracker/CVE-2018-16866