On ma, 10 tammi 2022, Rob Crittenden via FreeIPA-users wrote:
Rob Verduijn via FreeIPA-users wrote:
> Hello.
>
> Is there support in freeipa for howdy ?
>
https://github.com/boltgolt/howdy
>
> rpms are already available here:
>
https://copr.fedorainfracloud.org/coprs/principis/howdy/
>
> Would be nice if this would integrate with freeipa.
I wouldn't get your hopes up. Even the authors suggest that it isn't
particularly secure, which is the IPA raison d'être.
If someone submitted fully working code and the howdy packages were
available outside of copr, then maybe. As an optional method, disabled
by default.
I didn't dig into how howdy stores its authentication information but it
potentially brings with it privacy issues that we haven't had to deal
with before.
Right. As of now, howdy is more of a local-only tool tied to a
configuration and data available locally.
The way howdy is integrated into a system for authentication is by
providing a barebone PAM module which during authentication step runs a
Python script ('compare.py'). This script initializes camera and
captures frames to see if there is a particular human pose is present at
a frame and if a face there is one of the trained for in the local
database. Since PAM module stack during login runs as root, this process
would substantially increase an attack surface to cover all Python code
involved. There is plenty of code here that most likely was not analyzed
for security aspects.
Can this be turned into something that could be tied to a global (in
FreeIPA sense) identity? User-specific trained faces' database is
probably a privacy target as it could be (ab)used for detecting a person
in a photo or video frame out of the contex of deploying howdy for login
purpose. As such, I would not make it part of a user data in LDAP.
This makes centralized storage of this data questionable. Ok, if user
has the information in their home directory, perhaps howdy could be used
to consume that locally. This would be no different to authenticating a
user with pam_unix.so, after all.
Converting the fact that a user was authenticated with howdy to
something that would look as a centrally-issued mandate (Kerberos
ticket) is a harder task. Sure, we authenticated locally akin to
pam_unix.so, but this is not something that we can claim to a KDC in a
request of TGT. Could pam_howdy.so be used to unlock access to a vault
with, say, a PKINIT certificate for the user so that we would use this
fact for acquring a Kerberos TGT? May be. It would certainly be a
stretch of security trust here since there is literally nothing in howdy
cryptography-wise to allow a leap of mathematically strong operation
between face / pose recognition and a vault opening.
In Windows world how Windows Hello works in a domain environment is by
tying the local authentication process into some known to a domain
controller identity -- machine account of the system you are trying to
login to. That identity is known and mutually authenticated to a domain
controller and can ask for a ticket to itself on behalf of a user which
was externally validated. The 'leap of trust' is a bit complex, with
hardware requirement of TPM on the client, a lot of communication
with a DC like in this diagram, and additional communication to the
cloud AP to finally tie the domain identity to Azure AD identity:
https://docs.microsoft.com/en-us/windows/security/identity-protection/hel...
All this is done to allow different Windows Hello logon types, not just
face recognition, to inherit domain-derived user properties for the
particular logon. Howdy doesn't have any secure binding of the data used
for authentication to a user account, and we cannot easily get a leap
from 'user data exists in this home directory' to 'issue Kerberos ticket
to this identity' without additional steps KDC could trust.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland