¿Cómo evitar que chgrp borre el "bit setuid"?

Tenemos imágenes de Linux basadas en HR; en el que tengo que "aplicar" algún "archivo especial" para actualizarlos a la última versión de desarrollo de nuestro producto.

La persona que creó el archivo pensó que dentro de nuestra imagen base, algunos permisos son incorrectos; entonces nos dijeron que corrieramos

sudo chgrp -R nobody /whatever

Nosotros hicimos eso; y más tarde, cuando nuestra aplicación se está ejecutando, surgieron problemas oscuros.

Lo que encontré más adelante: la llamada a chgrp va a borrar la información de bit setuid en nuestros archivos binarios en / lo que sea.

Y el problema real es: algunos de nuestros binarios deben tener ese bit setuid establecido para funcionar correctamente.

Larga historia corta: ¿hay alguna manera de ejecutar ese comando "chgrp" sin matar mis bits setuid?

Acabo de ejecutar lo siguiente en mi Ubuntu local; conduciendo al mismo resultado:

mkdir sticky
cd sticky/
touch blub
chmod 4755 blub 
ls -al blub 

-> me muestra el nombre del archivo con fondo rojo -> entonces, sí, setuid

chgrp -R myuser .
ls -al blub 

-> me muestra el nombre del archivo sin fondo rojo -> setuid se ha ido

Si desea implementar su chgrp -R nobody /whatevermientras retiene el bit setuid, puede usar estos dos findcomandos

find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
                                      -exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +

La find ... -perm 04000opción recoge archivos con el conjunto de bits setuid. El primer comando luego aplica el chgrpy luego a chmodpara restablecer el bit setuid que ha sido eliminado. El segundo se aplica chgrpa todos los archivos que no tienen un bit setuid.

En cualquier caso, no desea llamar chgrpo chmoden enlaces simbólicos ya que eso afectaría a sus objetivos, de ahí el ! -type l.

Borrar bits SUID y SGID en chgrp(o chown) es perfectamente razonable. Es una medida de seguridad para evitar problemas de seguridad. Para SGID (en ejecutables, supongo) significa ejecutar este programa con un grupo efectivo del propietario del grupo .

Si cambia el propietario del grupo, entonces, en términos de seguridad y control de acceso, esto es algo completamente diferente, es decir, en lugar de ejecutarse con un grupo efectivo, uvwel programa ahora se ejecuta con un grupo efectivo xyz.

Por lo tanto, debe restaurar el bit SUID o SGID explícitamente en el cambio de propiedad.

Anexo: En el reclamo de que chgrp (o chown) solo debe borrar SGID (o SUID, resp.)

Al cambiar chowno chgrpcambiar la configuración de seguridad de un ejecutable, esta es una razón suficiente para borrar cualquier atributo de elevación de privilegios. El poder de Unix proviene de la simplicidad conceptual, y la seguridad de Unix ya es bastante complicada. Con este fin, eliminar SUID y SGID en cualquier cambio de propiedad es simplemente una red de seguridad: después de todo, en la historia de Unix / Linux hubo bastantes vulnerabilidades debido a la configuración equivocada de SUID o SGID.

Entonces, no hay una razón más profunda por la cual Unix se comporta de esta manera, es solo una decisión de diseño conservadora.

La eliminación del bit setuid, setgid(al menos en Linux) en los no directorios se realiza por el núcleo en la chown()llamada del sistema realizada por chgrp, no por chgrpsí mismo. Entonces, la única forma es restaurarlo después.

También borra las capacidades de seguridad.

Entonces, en GNU Linux:

chown_preserve_sec() (
  newowner=${1?}; shift
  for file do
    perms=$(stat -Lc %a -- "$file") || continue
    cap=$(getfattr -m '^security\.capability$' --dump -- "$file") || continue
    chown -- "$newowner" "$file" || continue
    [ -z "$cap" ] || printf '%s\n' "$cap" | setfattr --restore=-
    chmod -- "$perms" "$file"
  done
)

Y ejecuta (como root):

chown_preseve_sec :newgroup file1 file2...

para cambiar el grupo al intentar preservar los permisos.

Recurrentemente, podrías hacer:

# save permissions (and ACLs). Remove the "# owner" and "# group" lines
# to prevent them being restored!
perms=$(getfacl -RPn . | grep -vE '^# (owner|group): ')
# save capabilities
cap=$(getfattr -Rhm '^security\.capability$' --dump .)

chgrp -RP nobody .

# restore permissions, ACLs and capabilities
printf '%s\n' "$perms" | setfacl --restore=-
[ -z  "$cap" ] || printf '%s\n' "$cap" | setfattr -h --restore=-

(todo lo que se supone que nada está alterando los archivos al mismo tiempo).

Como es habitual en la administración, hay muchos caminos por recorrer.

La solución que puse en su lugar es la siguiente:

cd /home/me
getfacl -R /whatever > whatever-permissions.org 2> /dev/null

# A) change lines starting with      # group: root
# to                                 # group: whatineed
sed 's/^# group: root/# group: whatineed/g' whatever-permissions.org > whatever-permissions.new

# B) change lines with               group::x.y
# to                                 group::xwy
# (where x, y mean: whatever was there before)
sed 's/^group::\(.\).\(.\)/group::\1w\2/g' whatever-permissions.new > whatever-permissions.new

cd /
setfacl --restore /home/me/whatever-permissions.new