La actualización manual de la entrada del llavero evita el próximo acceso desde las herramientas GUI después: siempre pide permiso

Me topé con esto usando Tunnelblick y Viscosity. Al agregar una configuración a esas herramientas VPN, es posible en la GUI durante la primera conexión para especificar usuario y contraseña y guardarlos en el llavero. Las siguientes conexiones usarán las credenciales guardadas del llavero.

Sin embargo, si cambio la contraseña en el llavero usando el comando de terminal de seguridad (add-generic-password -Usaw) o a través de la aplicación de acceso al llavero, tanto Tunnelblick como Viscosity mostrarán el "Permiso para acceder al llavero: [Permitir, Permitir siempre, cancelar ]"-diálogo si intento conectarme la próxima vez.

¿Hay alguna forma de evitar este diálogo?

  • Busqué un poco en el código fuente de Tunnelblick, pero no pude encontrar una verificación de "manipulación de llavero" ni nada que pudiera forzar este diálogo desde el lado de Tunnelblick.
  • ¿Si es una protección de nivel de sistema operativo configurable?
Si edita una entrada de Llavero fuera de la aplicación, tiene sentido para mí que OS X le pida que confirme que desea que la aplicación pueda acceder a ella. Cuando hace clic en Permitir siempre, ¿no recuerda esa configuración?
Con "Permitir siempre" recuerda hasta que se cambia la contraseña (nuevamente). Sin embargo dudo que tenga sentido, que esto no sea configurable. Necesita privilegios de usuario elevados (dos veces) para cambiar la entrada, ¿por qué se le debe informar nuevamente al acceder por primera vez? Entiendo que alguna "verificación de integridad" podría ser útil, pero no es una advertencia detectable, es una ventana emergente de GUI tan pronto como intenta acceder al llavero (si entiendo correctamente el código fuente de Tunnelblick).
Múltiples aplicaciones pueden acceder a un solo elemento de llavero. En su caso, está modificando el elemento e intentando usarlo nuevamente en la misma aplicación, pero nuevamente lo está modificando fuera del alcance de la aplicación que autorizó previamente para usarlo. Por lo tanto, tiene mucho sentido que OS X quiera confirmar que tiene la intención de permitir el acceso a las credenciales actualizadas que están almacenadas, tal como lo haría si una aplicación intentara acceder a un elemento de llavero que no había creado.

Respuestas (1)

Para mac OS Sierra:

Para agregar un objeto y permitir el acceso (con el aviso del usuario), use la opción "-T Aplicación". (Se pueden utilizar varias aplicaciones)

security add-generic-password -a "account" -s "name" -w 'password' -c aapl -T /Applications/Utilities/Keychain\ Access.app/Contents/MacOS/Keychain\ Access

Luego, para permitir el acceso sin el aviso del usuario, debe modificar la ACL para el objeto:

security -v set-generic-password-partition-list -s "name" -S "apple:"

La sintaxis de la lista de particiones no está muy bien documentada. Es posible que pueda ver cómo Tunnelblick usa la ACL de la salida de "security dump-keychain".

Fuente: man security

Creo que esta es la respuesta correcta, sin embargo, usted y la documentación sugieren usar security dump-keychainpara buscar opciones de ejemplo para -S, pero no puedo ver nada allí para usar como ejemplo :(
La actualización manual de la entrada del llavero evita el próximo acceso desde las herramientas GUI después: siempre pide permiso
RespuestasAquíPolítica de privacidad1y, 0v