Hola @srd424. Quiero asegurarme de que entiendo lo que está pidiendo en este problema... me parece que básicamente le gustaría saber si libsecomp "sabe" acerca de una llamada al sistema determinada, independientemente de si esa llamada al sistema en particular está implementada en ese arco. /ABI, ¿sí?

Si es así, creo que debería poder usar seccomp_syscall_resolve_name(...) para obtener la información que desea. Si el valor devuelto es __NR_SCMP_ERROR , libseccomp desconoce la llamada al sistema, si es positiva, la llamada al sistema existe en el arco nativo/ABI, y si es negativa, la llamada al sistema no existe en el arco nativo/ ABI. Eso funciona para ti?

Eso podría hacer que los filtros ... ¡prolongados!

Lo que esperaba hacer es tener una regla de filtro que compare el número de llamada al sistema con el más alto conocido y, si es mayor, devolver ENOSYS ; de lo contrario, devolver EPERM (suponiendo que se hayan manejado las llamadas al sistema incluidas en la lista blanca por una regla anterior).

Sin embargo, mirando los detalles de seccomp_rule_add , no estoy seguro de que vaya a funcionar... el número de llamada al sistema se trata de manera especial. Presumiblemente, se podría construir un filtro bpf sin procesar para hacer esto, pero eso significará algunos cambios más invasivos en libseccomp, ¡probablemente por encima de mi nivel de pago!

Podría o no ser una funcionalidad razonable agregar a libseccomp, ya que supongo que el problema original puede ocurrir para múltiples usuarios de la biblioteca. Parece que sería (¿simplemente?) una cuestión de generar una acción predeterminada un poco más sofisticada.

Eso podría hacer que los filtros ... ¡prolongados!

No estoy muy seguro de lo que quieres decir aquí ... ? La llamada a seccomp_syscall_resolve_name(...) realidad no afecta el filtro, solo consulta la base de datos syscall interna de libseccomp para hacer la resolución de la llamada al sistema. Puedes llamarlo una vez, mil veces o nunca y tu filtro será exactamente el mismo :)

Lo que esperaba hacer es tener una regla de filtro que compare el número de llamada al sistema con el más alto conocido y, si es mayor, devolver ENOSYS; de lo contrario, devolver EPERM (suponiendo que las llamadas al sistema incluidas en la lista blanca hayan sido manejadas por una regla anterior).

Bien, creo que estoy empezando a entender lo que estás pidiendo ahora. ¿Desea que el filtro en sí, no el código de la aplicación, realice una determinada acción (devuelva ENOSYS en el ejemplo anterior) si libseccomp desconoce la llamada al sistema? ¿Es eso básicamente, o me estoy perdiendo algo otra vez?

Este comentario en el segundo hilo mencionado anteriormente me hizo sonreír :+1:

Intenté abrir una discusión sobre el manejo de ENOSYS en libseccomp en
https://github.com/seccomp/libseccomp/issues/286 , pero probablemente no
siendo muy coherente..

Después de leer los hilos que mencionaste, creo que estoy en la misma página.

Si alguien (libseccomp, nspawn, quien sea) pudiera devolver ENOSYS , entonces glibc intentará retroceder desde la llamada al sistema más nueva, por ejemplo, openat2 , a la llamada al sistema más antigua, por ejemplo, openat . Devolver EPERM a glibc solo hace que glibc piense que la llamada no fue permitida, y glibc se rendirá. ¿Es una reformulación justa del comentario inicial en este número?

Creo que la petición es razonable. Necesito pensar un poco más si libseccomp puede satisfacer estas necesidades, pero no tengo objeciones en este momento. Definitivamente hay oportunidades para mejorar la experiencia del usuario final aquí.

Gracias por la RFE.

Si alguien (libseccomp, nspawn, quien sea) pudiera devolver ENOSYS , entonces glibc intentará retroceder desde la llamada al sistema más nueva, por ejemplo, openat2 , a la llamada al sistema más antigua, por ejemplo, openat . Devolver EPERM a glibc solo hace que glibc piense que la llamada no fue permitida, y glibc se rendirá. ¿Es una reformulación justa del comentario inicial en este número?

Sí, eso suena bien. La opinión de la gente de systemd es que EPERM es razonable la mayor parte del tiempo para llamadas de sistema denegadas, presumiblemente porque transmite "no permitido" al usuario final/administrador. De ahí la idea de distinguir entre llamadas al sistema "nuevas" y "antiguas" y hacer ENOSYS para cualquier cosa no reconocida. Supongo que no queremos enumerar y probar cada syscall en el BPF por razones de rendimiento, por lo que el seguimiento de una marca de agua alta para los números de syscall conocidos por arco parecía una forma de "mejor esfuerzo".

Sería interesante saber qué hacen docker, podman, lxc, etc. con su filtrado seccomp, para ver si se beneficiarían. Mientras tanto, hice PR un parche para nspawn que permitiría el registro de eventos seccomp, lo que facilitaría un poco la depuración.

Creo que la petición es razonable. Necesito pensar un poco más si libseccomp puede satisfacer estas necesidades, pero no tengo objeciones en este momento. Definitivamente hay oportunidades para mejorar la experiencia del usuario final aquí.

Gracias por la RFE.

Estoy de acuerdo con @drakenclimber , esta solicitud suena razonable, creo que solo necesito más tiempo para pensar en posibles soluciones :)

En un nivel bastante básico, esto es similar a RFE # 11 y, al final, esa puede ser la forma más fácil de implementar esto de una manera que no sea terrible para las aplicaciones: una aplicación puede especificar una versión de API de kernel máxima compatible, por ejemplo. v5.8 (obviamente tokenizado), así como una acción dada para cualquier cosa más allá y luego libseccomp se encarga del resto. ¿Eso funcionaría para ustedes @srd424?

Hola, esto también se discutió en https://github.com/systemd/systemd/pull/16739.

una aplicación puede especificar una versión de API de kernel máxima admitida, por ejemplo, v5.8 (obviamente tokenizada), así como una acción dada para cualquier cosa más allá y luego libseccomp se encarga del resto.

Esto funcionaría muy bien. En systemd/systemd-nspawn, nos gustaría devolver errnos personalizados para cualquier llamada al sistema explícitamente permitida y denegada, EPERM para cualquier otra en la "versión compatible de la API del kernel" y ENOSYS para las nuevas.

Creo que la implementación no sería demasiado complicada. Por ejemplo, para amd64, las llamadas al sistema "conocidas" se pueden expresar como n <= 181 || 186 <= n <= 235 || 237 <= n <= 334 || 424 <= n <= 439 . Y tales expresiones se pueden generar fácilmente mediante programación a partir de las tablas syscall.

94 también podría estar relacionado.

Tengo poca cafeína esta mañana, pero tener el manejo de ENOSYS nos daría la posibilidad de convertir grandes listas permitidas en pequeñas listas de rechazo para una posible ganancia de rendimiento también.

Creo que la implementación no sería demasiado complicada. Por ejemplo, para amd64, las llamadas al sistema "conocidas" se pueden expresar como n <= 181 || 186 <= norte <= 235 || 237 <= norte <= 334 || 424 <= n <= 439. Y tales expresiones se pueden generar fácilmente programáticamente a partir de las tablas syscall.

Como usted menciona, el BPF real será específico tanto para arch/ABI como para la versión del kernel. En el ejemplo anterior de x86_64, el BPF no será tan malo, pero no tendremos tanta suerte con otros arcos/versiones. De todos modos, ahora hay dos problemas que solicitan lo mismo de manera efectiva, así que creo que es algo que querremos hacer... No voy a empezar a saltar de un lado a otro sobre lo fácil que va a ser todavía; )

94 también podría estar relacionado.

Más o menos sí, más o menos no. Se trata de rangos, pero el n.° 94 se trata de rangos de argumentos especificados por la persona que llama (lo cual sigue siendo algo que creo que queremos hacer, el PR llegó en un mal momento y creo que la API necesita algunos ajustes), mientras que de lo que estamos hablando es rangos de llamada al sistema creados implícitamente que son generados por la propia biblioteca.

Tengo poca cafeína esta mañana, pero tener el manejo de ENOSYS nos daría la posibilidad de convertir grandes listas permitidas en pequeñas listas de rechazo para una posible ganancia de rendimiento también.

Desde la perspectiva de la aplicación, por ejemplo, systemd, si está tratando de bloquear "nuevas" llamadas al sistema, entonces sí ... suponiendo que estemos hablando de lo mismo :)

Para ser más específicos... en este momento, cualquier persona que intente bloquear de manera _segura_ ciertas llamadas al sistema tiene que incluirlas en la lista de permitidos, porque no puede estar seguro de qué llamadas al sistema podría agregar un kernel más nuevo. Si podemos solicitar a libseccomp que bloquee automáticamente las llamadas al sistema desconocidas, ¿eso significa que podemos cambiar de forma segura a una pequeña lista de denegación?

Para ser más específicos... en este momento, cualquier persona que intente bloquear de manera _segura_ ciertas llamadas al sistema tiene que incluirlas en la lista de permitidos, porque no puede estar seguro de qué llamadas al sistema podría agregar un kernel más nuevo. Si podemos solicitar a libseccomp que bloquee automáticamente las llamadas al sistema desconocidas, ¿eso significa que podemos cambiar de forma segura a una pequeña lista de denegación?

Espero sinceramente que podamos llegar allí, ya que sería una característica absolutamente increíble. Por ejemplo, Docker actualmente emplea una lista de permitidos y su lista predeterminada ahora es de aproximadamente 240 llamadas al sistema (y sigue creciendo).

El impacto en el rendimiento de una lista tan grande puede ser prohibitivo. Tenga en cuenta que se puede mitigar un poco usando la función de árbol binario que agregamos en v2.5.

Para ser más específicos... en este momento, cualquier persona que intente bloquear de manera _segura_ ciertas llamadas al sistema tiene que incluirlas en la lista de permitidos, porque no puede estar seguro de qué llamadas al sistema podría agregar un kernel más nuevo. Si podemos solicitar a libseccomp que bloquee automáticamente las llamadas al sistema desconocidas, ¿eso significa que podemos cambiar de forma segura a una pequeña lista de denegación?

No veo cómo podría funcionar esto. Desconocido para libseccomp y desconocido para el autor de la lista de denegación generalmente significan cosas diferentes. Lo que significa que el problema conceptual no desaparecerá incluso si libseccomp tiene una imagen más clara de las llamadas al sistema admitidas internamente.

Buen punto: supongo que necesitaríamos conjuntos bien definidos etiquetados por versión del kernel para que funcione, lo que parece estar discutiéndose un poco.

Creo que la implementación no sería demasiado complicada. Por ejemplo, para amd64, las llamadas al sistema "conocidas" se pueden expresar como n <= 181 || 186 <= norte <= 235 || 237 <= norte <= 334 || 424 <= n <= 439. Y tales expresiones se pueden generar fácilmente programáticamente a partir de las tablas syscall.

Como usted menciona, el BPF real será específico tanto para arch/ABI como para la versión del kernel. En el ejemplo anterior de x86_64, el BPF no será tan malo, pero no tendremos tanta suerte con otros arcos/versiones. De todos modos, ahora hay dos problemas que solicitan lo mismo de manera efectiva, así que creo que es algo que querremos hacer... No voy a empezar a saltar de un lado a otro sobre lo fácil que va a ser todavía; )

Las tablas son bastante continuas:

>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-x86_64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  5,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1, 90,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-alpha').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([ 1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  3,  1,  2,  1,  1,
        1,  1,  1,  2,  1,  1,  1,  3, 12,  3,  3,  1, 11,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        2,  1,  1,  1,  1,  1,  1,  5,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1, 39,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  3,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        1,  1,  1,  1,  1,  1,  2,  1,  1,  1,  1,  1,  1,  1,  1,  1,  1,
        2,  1,  1,  1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-arm').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 1, 1, 3, 1, 1, 2, 1, 2, 3, 4,
       1, 2, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 2, 1, 1, 1, 2, 1, 2, 3, 1, 1,
       1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 2, 2, 1, 1, 1, 3,
       1, 1, 1, 1, 1, 1, 2, 1, 3, 1, 1, 1, 1, 1, 3, 3, 1, 1, 2, 1, 1, 1,
       1, 2, 1, 1, 2, 1, 2, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1,
       1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])
>>> l = {int(s[1]):s[0] for s in (s.split() for s in open('syscalls-riscv64').readlines()) if len(s)>1}; x = np.array(sorted(l.keys())); np.diff(x)
array([  1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   2,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,  16,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1, 130,   1,   1,   1,   1,   1,   1,   1,
         1,   1,   1,   1,   1,   1,   1,   1])

Implementé un filtro de llamadas al sistema "conocidas" para systemd-nspawn en https://github.com/systemd/systemd/pull/16819. https://github.com/systemd/systemd/pull/16819/commits/158e30ffd9355a7640a7276276eb9219b6c87914 tiene un volcado de algunos programas generados por libseccomp. Esos volcados son largos, así que no los repetiré aquí, pero SCMP_FLTATR_CTL_OPTIMIZE hace que el programa sea más eficiente, pero también más largo. Las cosas podrían acortarse unas 50 veces mediante el uso de comparaciones de rango.

Acabo de encontrar este hilo, solo intervino para decir que he estado pensando en líneas similares y esto es definitivamente algo que a Docker/runc también le gustaría haber resuelto. Hacerlo con una versión máxima del kernel es probablemente la mejor manera de hacerlo, porque significa que los escritores de perfiles (y los tiempos de ejecución de los contenedores) no necesitan rastrear las llamadas al sistema agregadas fuera de servicio o cuál era la llamada al sistema más reciente en el momento de escribir este artículo. el perfil.

Según la discusión anterior, parece que la mayoría (¿todas?) de las personas aquí creen que el problema n. ° 11 es la forma correcta de resolver este problema; ¿Alguien tiene algún problema con cerrar este problema a favor de mover la discusión futura al problema original (#11)?