La sobrecarga de FAPolicyD ralentiza un servidor

Question

Permitir enumerar los programas ejecutados se encuentra entre las funciones de seguridad más efectivas. Sin él, una cuenta de usuario comprometida podría ejecutar cualquier carga útil arbitraria. O los usuarios instalan programas en su directorio de inicio que no deberían. Aunque es una característica opcional que tú decides habilitar o no.

La inspección de todas estas llamadas al sistema de archivos afecta al rendimiento. Aunque la sobrecarga se puede minimizar optimizando las reglas y la base de datos.

Mida si el rendimiento es aceptable desde la perspectiva del usuario. Un objetivo centrado en el tiempo de respuesta, algo así como "el 99,9% de las llamadas API de aplicaciones se completarán en menos de 1 segundo", detectará problemas reales, no sólo tendencias en la utilización de recursos.

Primero, para conocer algunos antecedentes sobre fapolicyd, observe la introducción al rendimiento deel LÉAME:

ACTUACIÓN

Cuando un programa abre un archivo o llama a execve, ese hilo tiene que esperar a que fapolicyd tome una decisión. Para tomar una decisión, fapolicyd tiene que buscar información sobre el proceso y el archivo al que se accede. Cada llamada al sistema que fapolicyd debe realizar ralentiza el sistema.

Para acelerar las cosas, fapolicyd almacena en caché todo lo que busca para que el acceso posterior utilice el caché en lugar de buscar cosas desde cero. Pero el caché no es tan grande. Pero tú tienes el control. Puede agrandar las cachés de sujetos y objetos. Cuando finalice el programa, generará alguna estadística de rendimiento como esta en /var/log/fapolicyd-access.log o en la pantalla:
Permissive: false
q_size: 640
Inter-thread max queue depth 7
Allowed accesses: 70397
Denied accesses: 4
Trust database max pages: 14848
Trust database pages in use: 10792 (72%)

Subject cache size: 1549
Subject slots in use: 369 (23%)
Subject hits: 70032
Subject misses: 455
Subject evictions: 86 (0%)

Object cache size: 8191
Object slots in use: 6936 (84%)
Object hits: 63465
Object misses: 17964
Object evictions: 11028 (17%)
En este informe, puede ver que la cola de solicitudes interna alcanzó un máximo de 7. Esto significa que el demonio tenía como máximo 7 subprocesos/procesos en espera. Esto muestra que tuvo un poco de copia de seguridad, pero estaba manejando las solicitudes con bastante rapidez. Si este número fuera grande, como más de 200, entonces puede ser necesario aumentar q_size. Tenga en cuenta que si supera 1015, es posible que sea necesario indicarle a systemd que permita más de 1024 descriptores. En el archivo fapolicyd.service, deberá agregar LimitNOFILE=16384 o algún número mayor que su cola.

Otra estadística que vale la pena considerar es la proporción de aciertos y desalojos. Cuando una solicitud no tiene dónde poner información, tiene que desalojar algo para hacer espacio. Esto se hace mediante un caché LRU que naturalmente determina qué no se utiliza y deja su memoria disponible para su reutilización.

En las estadísticas anteriores, la tasa de aciertos de los sujetos fue del 95%. El caché de objetos no tuvo tanta suerte. Por ello, obtenemos un ratio de acierto del 79%. Esto sigue siendo bueno, pero podría ser mejor. Esto sugeriría que para la carga de trabajo de ese sistema, el caché podría ser un poco mayor. Si el número utilizado para el tamaño de la caché es un número primo, obtendrá menos abandono de la caché debido a colisiones que si tuviera un denominador común. Algunos números primos que podría considerar para el tamaño de la caché son: 1021, 1549, 2039, 4099, 6143, 8191, 10243, 12281, 16381, 20483, 24571, 28669, 32687, 40961, 49157, 57353. , etc.

Además, cabe mencionar que cuantas más reglas haya en la política, más reglas tendrá que iterar para tomar una decisión. En cuanto al impacto en el rendimiento del sistema, depende en gran medida de la carga de trabajo. En un escenario de escritorio típico, no notarás que se está ejecutando. Un sistema que abre muchos archivos aleatorios durante períodos cortos de tiempo tendrá más impacto.

Otra opción de configuración que puede afectar el rendimiento es la configuración de integridad. Si se establece en sha256, cada error en la caché de objetos provocará que se calcule un hash en el archivo al que se accede. Una compensación sería utilizar la verificación de tamaño en lugar de sha256. Esto no es tan seguro, pero es una opción si el rendimiento es problemático.

do_stat_report = 1en la configuración para habilitar el informe de estadísticas, luego reinicie fapolicyd si no lo ha hecho recientemente. Analice /var/log/fapolicyd-access.log y observe los patrones de qué PID abren qué archivos.

Tenga en cuenta la proporción de "aciertos" y "fallos". Una tasa de aciertos más alta es mejor; acceder a la base de datos en memoria es mucho más rápido que acceder y procesar el sistema de archivos. Aumente obj_cache_sizela configuración a la cantidad de archivos que su sistema tiene a la vez. Un posible límite superior es el número de inodos utilizados en el sistema de archivos de datos, a partir de df -ila salida. Lo cual puede ser excesivo, pero si tienes memoria, ¿por qué no almacenar en caché un par de cientos de miles de entradas?

Revise la configuración en fapolicyd.conf. integritylos valores distintos de noneo sizecalcularán la suma de comprobación y tendrán gastos generales. Especialmente si tiene muchos fallos al procesar archivos nuevos, esto podría representar una cantidad significativa de CPU. q_sizedebe ser mayor que la "profundidad máxima de la cola" en el informe de acceso; sin embargo, dudo que sea necesario aumentar el tamaño de la cola.

Revisar las reglas, en reglas compiladas de reglas.d. RHEL y Fedora completan archivos confiables desde rpm, no permiten la ejecución de archivos desconocidos, no permiten el truco ld.so y permiten la mayoría de las aperturas. Si modifica las reglas, piense en el impacto en el rendimiento de hacer más cosas mientras esa llamada al sistema abierta está esperando.

Y, como siempre, puede perfilar qué sucede exactamente mientras soluciona el problema. perf topimprimirá qué funciones hay en la CPU, y es aún mejor cuando se instala debuginfo. El paquete bcc-tools tiene algunos scripts interesantes: opensnoop y execsnoop para enumerar las llamadas abiertas y exeve en tiempo real.

En última instancia, es su decisión qué controles implementar para permitir sólo la ejecución de programas no autorizados. La lista de permitidos inmediatamente en la llamada ejecutiva, como fapolicyd, es, por supuesto, muy poderosa. Una alternativa menos completa podría ser restringir el acceso al shell: no permitir shells interactivos a las personas y bloquear los permisos de los directorios de inicio. O, si un sistema de archivos de datos no tiene ningún programa, considere montarlo noexec. Una buena auditoría de seguridad no trataría la lista de verificación como inmutable, sino que enumeraría controles alternativos implementados y por qué.

Answer 1

Permitir enumerar los programas ejecutados se encuentra entre las funciones de seguridad más efectivas. Sin él, una cuenta de usuario comprometida podría ejecutar cualquier carga útil arbitraria. O los usuarios instalan programas en su directorio de inicio que no deberían. Aunque es una característica opcional que tú decides habilitar o no.

La inspección de todas estas llamadas al sistema de archivos afecta al rendimiento. Aunque la sobrecarga se puede minimizar optimizando las reglas y la base de datos.

Mida si el rendimiento es aceptable desde la perspectiva del usuario. Un objetivo centrado en el tiempo de respuesta, algo así como "el 99,9% de las llamadas API de aplicaciones se completarán en menos de 1 segundo", detectará problemas reales, no sólo tendencias en la utilización de recursos.

Primero, para conocer algunos antecedentes sobre fapolicyd, observe la introducción al rendimiento deel LÉAME:

ACTUACIÓN

Cuando un programa abre un archivo o llama a execve, ese hilo tiene que esperar a que fapolicyd tome una decisión. Para tomar una decisión, fapolicyd tiene que buscar información sobre el proceso y el archivo al que se accede. Cada llamada al sistema que fapolicyd debe realizar ralentiza el sistema.

Para acelerar las cosas, fapolicyd almacena en caché todo lo que busca para que el acceso posterior utilice el caché en lugar de buscar cosas desde cero. Pero el caché no es tan grande. Pero tú tienes el control. Puede agrandar las cachés de sujetos y objetos. Cuando finalice el programa, generará alguna estadística de rendimiento como esta en /var/log/fapolicyd-access.log o en la pantalla:
Permissive: false
q_size: 640
Inter-thread max queue depth 7
Allowed accesses: 70397
Denied accesses: 4
Trust database max pages: 14848
Trust database pages in use: 10792 (72%)

Subject cache size: 1549
Subject slots in use: 369 (23%)
Subject hits: 70032
Subject misses: 455
Subject evictions: 86 (0%)

Object cache size: 8191
Object slots in use: 6936 (84%)
Object hits: 63465
Object misses: 17964
Object evictions: 11028 (17%)
En este informe, puede ver que la cola de solicitudes interna alcanzó un máximo de 7. Esto significa que el demonio tenía como máximo 7 subprocesos/procesos en espera. Esto muestra que tuvo un poco de copia de seguridad, pero estaba manejando las solicitudes con bastante rapidez. Si este número fuera grande, como más de 200, entonces puede ser necesario aumentar q_size. Tenga en cuenta que si supera 1015, es posible que sea necesario indicarle a systemd que permita más de 1024 descriptores. En el archivo fapolicyd.service, deberá agregar LimitNOFILE=16384 o algún número mayor que su cola.

Otra estadística que vale la pena considerar es la proporción de aciertos y desalojos. Cuando una solicitud no tiene dónde poner información, tiene que desalojar algo para hacer espacio. Esto se hace mediante un caché LRU que naturalmente determina qué no se utiliza y deja su memoria disponible para su reutilización.

En las estadísticas anteriores, la tasa de aciertos de los sujetos fue del 95%. El caché de objetos no tuvo tanta suerte. Por ello, obtenemos un ratio de acierto del 79%. Esto sigue siendo bueno, pero podría ser mejor. Esto sugeriría que para la carga de trabajo de ese sistema, el caché podría ser un poco mayor. Si el número utilizado para el tamaño de la caché es un número primo, obtendrá menos abandono de la caché debido a colisiones que si tuviera un denominador común. Algunos números primos que podría considerar para el tamaño de la caché son: 1021, 1549, 2039, 4099, 6143, 8191, 10243, 12281, 16381, 20483, 24571, 28669, 32687, 40961, 49157, 57353. , etc.

Además, cabe mencionar que cuantas más reglas haya en la política, más reglas tendrá que iterar para tomar una decisión. En cuanto al impacto en el rendimiento del sistema, depende en gran medida de la carga de trabajo. En un escenario de escritorio típico, no notarás que se está ejecutando. Un sistema que abre muchos archivos aleatorios durante períodos cortos de tiempo tendrá más impacto.

Otra opción de configuración que puede afectar el rendimiento es la configuración de integridad. Si se establece en sha256, cada error en la caché de objetos provocará que se calcule un hash en el archivo al que se accede. Una compensación sería utilizar la verificación de tamaño en lugar de sha256. Esto no es tan seguro, pero es una opción si el rendimiento es problemático.

do_stat_report = 1en la configuración para habilitar el informe de estadísticas, luego reinicie fapolicyd si no lo ha hecho recientemente. Analice /var/log/fapolicyd-access.log y observe los patrones de qué PID abren qué archivos.

Tenga en cuenta la proporción de "aciertos" y "fallos". Una tasa de aciertos más alta es mejor; acceder a la base de datos en memoria es mucho más rápido que acceder y procesar el sistema de archivos. Aumente obj_cache_sizela configuración a la cantidad de archivos que su sistema tiene a la vez. Un posible límite superior es el número de inodos utilizados en el sistema de archivos de datos, a partir de df -ila salida. Lo cual puede ser excesivo, pero si tienes memoria, ¿por qué no almacenar en caché un par de cientos de miles de entradas?

Revise la configuración en fapolicyd.conf. integritylos valores distintos de noneo sizecalcularán la suma de comprobación y tendrán gastos generales. Especialmente si tiene muchos fallos al procesar archivos nuevos, esto podría representar una cantidad significativa de CPU. q_sizedebe ser mayor que la "profundidad máxima de la cola" en el informe de acceso; sin embargo, dudo que sea necesario aumentar el tamaño de la cola.

Revisar las reglas, en reglas compiladas de reglas.d. RHEL y Fedora completan archivos confiables desde rpm, no permiten la ejecución de archivos desconocidos, no permiten el truco ld.so y permiten la mayoría de las aperturas. Si modifica las reglas, piense en el impacto en el rendimiento de hacer más cosas mientras esa llamada al sistema abierta está esperando.

Y, como siempre, puede perfilar qué sucede exactamente mientras soluciona el problema. perf topimprimirá qué funciones hay en la CPU, y es aún mejor cuando se instala debuginfo. El paquete bcc-tools tiene algunos scripts interesantes: opensnoop y execsnoop para enumerar las llamadas abiertas y exeve en tiempo real.

En última instancia, es su decisión qué controles implementar para permitir sólo la ejecución de programas no autorizados. La lista de permitidos inmediatamente en la llamada ejecutiva, como fapolicyd, es, por supuesto, muy poderosa. Una alternativa menos completa podría ser restringir el acceso al shell: no permitir shells interactivos a las personas y bloquear los permisos de los directorios de inicio. O, si un sistema de archivos de datos no tiene ningún programa, considere montarlo noexec. Una buena auditoría de seguridad no trataría la lista de verificación como inmutable, sino que enumeraría controles alternativos implementados y por qué.

La sobrecarga de FAPolicyD ralentiza un servidor

Respuesta1

ACTUACIÓN

información relacionada