¿Cómo abordar la creación de una aplicación de Linux que requiera privilegios de root?

No hay realmente una respuesta correcta a esta pregunta. Es un intercambio entre seguridad y usabilidad.

  

ejecutar el comando con pkexec cada vez (lo que quiero evitar para la experiencia del usuario);

Si la audiencia deseada no tiene "CLIphobia", sudo podría ser realmente genial aquí si "cada vez" esté dentro de los 15 minutos.

Pero desde un punto de vista de seguridad, recomendaría pkexec. Supongo que se puede confiar ya que viene preinstalado con la distro, a diferencia de algunos envoltorios o demonios setuid rápidamente pirateados.

  

ya que el indicador está en python, podría tener un binario con el conjunto de bits setuid escrito en C. Sin embargo, me han dicho que este enfoque está mal visto;

El único problema que he escuchado de los envoltorios setuid es que pueden sobrescribirse con un troyano si lo explotan, pero esto no es relevante para setuid-to- / root / binaries como cualquier vulnerabilidad. en un proceso que se ejecuta como root significa que estás jodido de todos modos.

El único problema que he experimentado tampoco se aplica a setuid-to- / root / binaries, fue así que no entendí todas las ID de usuario de Unix y olvidé configurar el usuario real. ID, ID de usuario guardada y sus equivalentes de ID de grupo, esto significa que un programa que / drops / privileges aún puede recuperarlos.

Podría haber otras razones por las que los envoltorios de setuid están mal vistos, pero no he oído hablar de ninguno. Si nadie más puede encontrar razones por las que los envoltorios de setuid son mal vistos, un envoltorio de setuid será una muy buena elección.

  

inicie un "proxy" que se ejecutará como root y solo realizará esa tarea específica, y el indicador se comunicará con ese "proxy"

Si crea un demonio para realizar la tarea, manténgalo tan simple como sea posible y asegúrese de que los usuarios no autorizados no puedan comunicarse con él.

Puedo pensar en dos opciones: (1) usar una contraseña que un cliente autorizado sabría, el demonio sabe y un cliente no autorizado no sabe. La contraseña debería almacenarse en un archivo con código 400 y propiedad de root.

(2) use los permisos de Unix en el socket para evitar que cualquier otro usuario local intente (ab) usar el demonio. enlace

La opción dos puede considerarse menos segura y más inconsistente en UX. Es posible que el usuario no entienda por qué no funcionará cuando haya iniciado sesión como un usuario diferente, lo que es realmente malo cuando sucede.

Primero, me gustaría abordar la pregunta en el título:

  

¿Cómo abordar la creación de una aplicación de Linux que requiera privilegios de raíz?

No requiera u obtenga privilegios de root a menos que absolutamente, absolutamente los requiera. Más bien, como lo señala user2313067 en un comentario, use capacidades . Desde man 7 capabilities :

  

Comenzando con el kernel 2.2, Linux divide los privilegios tradicionalmente asociados con el superusuario en distintas unidades, conocidas como capacidades, que pueden habilitarse e inhabilitarse de forma independiente. Las capacidades son un atributo por hilo.

Linux 2.2 se lanzó a principios de 1999 y, como consecuencia, tiene más de 17 años de antigüedad. escribiendo esto Negarse a ejecutarse en kernels que no soportan capacidades no está fuera del alcance de lo razonable en estos días, incluso para software ampliamente distribuido.

Específicamente, en este caso, su proceso necesitaría la capacidad CAP_FOWNER , que entre otras cosas le dice al núcleo que:

  

Omita las comprobaciones de permisos en las operaciones que normalmente requieren que el UID del sistema de archivos coincida con el UID del archivo (por ejemplo, chmod(2) , utime(2) ), excluyendo las operaciones cubiertas por CAP_DAC_OVERRIDE y CAP_DAC_READ_SEARCH

En segundo lugar, en términos generales, el mejor enfoque es limitar los permisos extendidos en la medida de lo posible. En su caso, eso probablemente significa un pequeño programa diseñado para solo activar o desactivar el bit ejecutable en el archivo en cuestión, y nada más. Cree un programa pequeño, tal vez con el nombre del archivo relevante codificado en hardware (sugiero una macro #define si usa C, o algún mecanismo similar si usa otro idioma), que toma como entrada un único parámetro de un solo carácter que dice si el bit ejecutable debe ser Encendido o apagado. Realice un montón de comprobación de cordura y luego llame a stat () y chmod () ( no / usr / bin / stat y / bin / chmod) directamente con los parámetros apropiados. De esa manera, incluso si hay un error en su pequeño programa, se vuelve muy difícil aprovecharlo para hacer algo que no sea lo que fue pensado. Llame a este programa con una ruta completa, y asegúrese de que no pueda ser utilizado por ningún usuario no autorizado (y ciertamente no haya sido modificado por ninguno). Considere la posibilidad de compilarlo de forma estática para reducir el riesgo de ataques de precargadores de biblioteca.

Tercero, considere por qué necesita cambiar el bit ejecutable en primer lugar. ¿Está quizás utilizando el estado global para gestionar un problema local ? Puede haber una manera de lograr lo que está tratando de hacer sin tener que recurrir a los cambios de permisos en primer lugar. Asegúrese de haber agotado todas las demás opciones razonables antes de recurrir a un cambio en el estado global del sistema.