¿Pertenecen 'sudo' y 'su' a la seguridad basada en capacidades?

De hecho, los programas sudo y su no forman parte de ninguno de los modelos de seguridad por varias razones.

1. Los anillos de protección se refieren a los permisos de acceso de memoria / CPU y en el espacio de usuario, el único acceso es a los archivos.
2. Las capacidades se refieren a los permisos de proceso y, como programas independientes, son un proceso separado del llamante y no heredan ni regalan ninguna de sus capacidades en adelante.
3. Son programas de software independientes que no se ven afectados ni afectan al sistema operativo de ninguna manera.

Algunos antecedentes pueden ser relevantes aquí:
En Unix y Linux hay dos niveles de permisos: usuario estándar y superusuario (generalmente llamado root).
El usuario estándar solo tiene acceso a los archivos para los que tiene permisos, por propiedad, pertenencia a un grupo o ACL.
El superusuario tiene permisos para todo (ignoraremos cosas como SELinux y similares para esta respuesta) sin límites dentro del espacio de usuario .

Esto presenta un gran obstáculo que superar, ya que un usuario estándar no tiene acceso a los archivos del sistema. ¿Cómo podría realizarse algo como un cambio de contraseña? Para un cambio de contraseña, el usuario debe escribir en el archivo / etc / passwd o en el archivo shadow (su ubicación varía entre los diferentes tipos de Unix).

Para admitir este y otros casos similares, los sistemas Unix han introducido una forma de otorgar permisos especiales llamados bit suid. Esto es un poco en el sistema de archivos que cuando se configura en un ejecutable le permite obtener los privilegios del propietario del archivo en lugar del usuario que llama.

Sudo y Su utilizan este mecanismo para permitir que un usuario establezca sus permisos efectivos a los de otra persona (generalmente el superusuario, pero no siempre) para que puedan ejecutar programas normales que no tienen su conjunto de indicadores suid, como usuario aparte de la que iniciaron sesión como.

En Linux, sudo y su pertenecen a NEITHER to capability-based security,NOR to Protection Rings !

La seguridad basada en capacidades es un software o programa específico con un nivel de implementación mínimo (sudo y su no comparten ninguna capacidad y tienen y están muy lejos del principal de privilegios mínimos), ¡mientras que Anillos de protección aplica todo desde el nivel del procesador / CPU (sudo y su no tienen nada que ver con el procesador o la arquitectura jerárquica)!

Sudo se usa para ejecutar un comando en particular con permisos de raíz. Lo interesante es que cuando usa sudo para un comando en particular, el sistema le solicita la contraseña del usuario actual. Una vez que ingrese la contraseña, el comando se ejecuta con privilegios de raíz.

Su se usa para cambiar a cualquier cuenta de usuario. El sistema solicita la contraseña correspondiente al usuario cambiado. Si se usa su sin ninguna opción, se realiza un cambio a la cuenta de usuario root. En este caso, el sistema solicita la contraseña del usuario root.

  

Por ejemplo, al editar un archivo de sistema, generalmente necesitamos sudo o su para   Cambiar temporalmente al usuario root. ¿Este ejemplo pertenece a   ¿Seguridad basada en capacidades, o para anillos de protección?

No cambiamos al usuario root, pero solo aumentamos nuestro acceso / privilegio a ciertas acciones específicas y se ejecutan con privilegios de root. El proceso aún se ejecutaría bajo el mismo espacio de usuario, ¡la única diferencia de que el privilegio ha sido otorgado al de root! En realidad, todas estas cosas de accesibilidad se asignan al archivo /etc/sudoers , donde el acceso a cada una de las tareas, como la ejecución de ciertas aplicaciones, la modificación de la configuración del sistema, etc., se enumeran para cada sudoer. No todos los usuarios se mantienen en la lista de sudoers, ¡puede que haya varios usuarios excluidos de esto para la seguridad del sistema!

Entonces, cuando ejecutamos sudo OR su , implica una llamada del sistema al kernel, es decir, la llamada al sistema setuid() se invoca al kernel de Linux y luego el uid del usuario se establece en 0 (el de root) y, por lo tanto, aparece el indicador # , ¡todo se está haciendo en el mismo espacio de usuario y modo de usuario del usuario y no en el espacio de usuario de la raíz!