¿Por qué un usuario no privilegiado no puede cambiar la propiedad del archivo?


15

De chown (2):

Solo un proceso privilegiado (Linux: uno con la capacidad CAP_CHOWN) puede cambiar el propietario de un archivo. El propietario de un archivo puede cambiar el grupo del archivo a cualquier grupo del que ese propietario sea miembro. Un proceso privilegiado (Linux: con CAP_CHOWN) puede cambiar el grupo arbitrariamente.

¿Cuál es la razón de esta restricción? ¿Por qué un usuario sin privilegios no puede cambiar la propiedad de un archivo que posee (es decir, no / etc / shadow)?

$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted

Respuestas:


27

Al permitir que los usuarios "regalen" archivos, se topa con varias características del sistema operativo. Como:

Taking up another user's disk quota.
Impersonating another user (or even root) via setuid.
Having insufficient privileges to undo a mistaken chown.
Making it appear that someone else had created a given file.
Setting up cron jobs to run on other user's accounts.
And many more...

8

Es solo una elección personal de los diseñadores de Linux no permitirlo: todas las razones de pseudo-seguridad, dadas , son engañosas, ya que hay sistemas Unix que lo permiten.

Creo que esta funcionalidad se redujo a si el comportamiento de su Unix siguió o no 'System-V' (AT&T) o el Unix de Berkeley (BSD) ...

En cuanto a otros problemas de seguridad mencionados:

  • Hacerse pasar por otro usuario (o incluso root) a través de setuid.

    Sin problemas: el cambio de 'propietario' borra cualquier bit 'setXid' (U / G)

  • Tener privilegios insuficientes para deshacer una prenda equivocada

    No es realmente un "riesgo de seguridad", PERO, podría ser en sistemas que permiten cambiar de usuario, puede volver a cambiarlo si está en un directorio de su propiedad, de lo contrario: "¡tenga cuidado"!

  • Hacer que parezca que alguien más ha creado un archivo determinado.

    Todavía estaría en un directorio que usted pueda escribir. Es decir, no podría moverlo a su homedir, a menos que lo tenga abierto para escribir en su grupo o en todos (o específicamente si las ACL están disponibles).

  • Configurar trabajos cron para que se ejecuten en las cuentas de otros usuarios.

    Una vez más, no funcionaría - desde los crondirs son propiedad de usuario y no a establecer incluso ser legible por otros usuarios, y mucho menos escribir.

  • si alguien pudiera cambiar la propiedad, cualquiera podría cambiar los permisos para obtener acceso a cualquier archivo en el sistema.

    No: solo si el usuario 'posee' el directorio que contiene ese archivo. Es decir, puedo dar un archivo llamado 'passwd' a la raíz, pero no podría moverlo a / etc / a menos que tenga permiso de escritura a / etc /.

  • cuotas

    Un punto potencialmente válido: SI usa cuotas, pero parece que sería fácil de detectar si suma espacio en disco por home-dir; El único problema sería en directorios que pueden ser escritos por múltiples usuarios. En cuyo caso, tal vez va por el propietario de ese 'dir'. Es PUEDE ser el caso en los sistemas que soportan 'regalar' archivos, que sólo se puede hacer esto en directorios que 'propia', pero ha sido un largo tiempo desde que he estado realmente en un sistema que permite a este, por lo No recuerdo las restricciones exactas.

Me parece recordar que hubo una "compensación" por permitir "regalar archivos" ... por ejemplo, en sistemas que permitieron eso, no se permitió otra cosa que Linux permite, pero no puedo recordar lo que estaba apagado mano...

Yo diría que la 'respuesta' anterior no debe estar marcada como la respuesta, ya que NO es la respuesta real. Es más una decisión de diseño: simplemente no sé cuáles fueron las compensaciones.

Puede haber problemas de seguridad no mencionados anteriormente que serían preocupaciones válidas, pero los anteriores no son válidos.

En mi opinión, debería ser un 'valor' configurable por el sistema en "/ proc", pero en general, creo que a la mayoría de la gente no le importa mucho.

Si existiera una fuerte necesidad, 'chown' podría mejorar la seguridad y modificarse para permitirlo y luego configurarlo con 'root' de setuid para permitirle implementar dicha política.


Las cuotas siempre se basan en la propiedad del archivo , no en la ubicación . De lo contrario, alguien podría guardarlo todo /tmp.
user1686

+1, parece que tienes toda la razón :). En los sistemas OpenSolaris (que de hecho es un descendiente del Sistema V) puede establecer esto a través de una mountopción (por lo tanto, esta configuración puede limitarse a un único punto de montaje en lugar de ser de todo el sistema según su sugerencia de valor configurable por el sistema): rstchown(el valor predeterminado ) para limitar los cambios del propietario del archivo al usuario raíz, norstchownpara permitir que los usuarios sin privilegios cambien el propietario de sus propios archivos (no pueden volver a cambiarlo).
WhiteWinterWolf

6

Bueno, si alguien pudiera cambiar la propiedad, cualquiera podría cambiar los permisos para obtener acceso a cualquier archivo en el sistema. Esto es malo no solo desde el punto de vista del malware (no se requiere sudo), sino desde el punto de vista de un administrador de sistemas. Si alguno de los usuarios pudiera cambiar alguno de los archivos, entonces los permisos de los archivos son inútiles.


2
Correcto. Modifiqué la pregunta para dejarla clara, me refería a los archivos que posee el usuario y no a ningún archivo.
Alexandru

1
@Alexandru: piense en un usuario malintencionado que cambia myTrojan.shpara ser propiedad de root y tener un indicador SUID.
Benjamin Bannier

@honk: tiene sentido ahora.
Alexandru

5

Porque entonces el usuario puede evadir las cuotas del sistema de archivos. Si tengo una cuota de 100 MB y tienes una cuota de 100 MB, puedo cargar 100 MB, chmod a + r, mostrarte y luego cargar otros 100 MB.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.