¿Es posible usar un conjunto de bibliotecas C o llamadas al sistema para eliminar todos los privilegios de usuario en POSIX, o al menos en Linux? Tenga en cuenta que no estoy preguntando cómo eliminar los privilegios de root , que es lo que todos los demás resultados de búsqueda de StackOverflow parecen estar preguntando y respondiendo.
Quiero el mismo efecto que cambiar al usuario nobody , pero más fuerte si es posible. Es decir, quiero que mi aplicación C haga lo siguiente:
root , y sin el bit de permiso del archivo setuid$HOMEacceptCosas que he considerado hasta ahora que no se ajustan a la factura:
nobody con setuid / setgidnobody ), y la aplicación no debería requerir root solo para cambiar a nobody .root , no eliminan los privilegios de los usuarios ordinariosexit , sigreturn , read y writeCosas que parecen interesantes, pero para las que no pude encontrar documentación, parecen no tener mantenimiento o parecen no ser portátiles:
Entonces, ¿existe una forma bien documentada, preferiblemente portátil, de eliminar los privilegios de usuario no esenciales y aislar un proceso sin tener que convertirse primero en root ?
Es poco probable que alguna solución funcione en todos los POSIX, ya que POSIX no define el mecanismo que está buscando.
Mirando solo los requisitos y solo Linux, probablemente la forma más fácil de satisfacerlos es real a través de los módulos de seguridad. Cualquier apparmor, selinux, RBAC hará lo que necesite, pero solo a través de un perfil externo, no algo integrado en su aplicación. El problema puede ser que agregar un perfil en todos esos casos requiera que el usuario root lo haga (pero el perfil también se aplica al proceso del usuario).
Una solución un poco más complicada que casi satisface los requisitos es seccomp. Si bien no comprende las rutas en absoluto (solo puede ver los punteros), hay formas de limitar el acceso: las políticas seccomp se pueden definir por subproceso, por lo que podría rediseñar su sistema para tener un "subproceso de verificación de ruta", que no no hace nada aparte de leer rutas y devolver sockets si coinciden con su especificación. Luego limite ese hilo a solo recv() , open() y send() . El subproceso que realiza otro trabajo puede open() y usar el otro servicio.
O si puede configurar las rutas al inicio del programa, puede colocarlas en una matriz, marcar esa página como de solo lectura y configurar la política seccomp que solo aceptará open() con nombres de archivo de esa matriz (eso es solo una comparación de puntero en Ese caso).
Hasta cierto punto, el enfoque de dividir la aplicación en procesos separados que tienen responsabilidades muy limitadas es algo que podría replicarse en otros sistemas, pero sin las mismas garantías que en Linux. Por ejemplo, qmail es una especie de sistema de procesos muy pequeños que funcionan como canalización de datos (simplificación). En Linux, aún podría aplicarles seccomp, en Solaris simplemente suelte exec y otras capacidades, en otros sistemas ... No lo sé, pero probablemente pueda hacer algo.