On to, 15 syys 2022, Kevin Fenzi wrote:
On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
Proven packagers seem to be a fair category to address. Also packagers
responsible for security-related bits of the distribution. Compilers?
Well, as others noted in this thread, any packager has a lot of power.
They can add a weak dep on something everyone has installed and pull
their package in. Of course they likely only get to do that once.
There is probably a value in defining what functions critical to have
strongly authenticated and identified to the distribution at large. For
example, right now even 2FA OTP requirement is not mandatory for certain
package groups.
As far as I know, it's not possible to enforce otp per group is it?
That would be a nice enhancement.
It is on my radar.
Additionally, right now, packagers commit with ssh keys or oidc tokens,
in order for a 2fa setup to be effective, we would need to switch that
to kerberos or the like.
One thing I want to get properly implemented in SSSD in upcoming FIDO2
support is to allow admins to filter out certain types of public SSH
keys associated with the user account. E.g. get a way for administrator
to say 'only FIDO2 keys and their OpenSSH equivalents (ecdsa-sk,
ed25519-sk) allowed for these users' and let SSSD's
sss_ssh_authorized_keys to filter all other types. Then your git server
could be able to deny non-FIDO2 SSH keys on per-user base.
FreeIPA Kerberos already gives you this feature for various
authentication methods[1] but it is not integrated in OpenSSH's GSSAPI
support.
[1] https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy.html
these days than, say, FIDO2 tokens. A card reader cost is around 10EUR
(Amazon.de gives me ~100 options of USB smartcard readers below 20EUR),
a smartcard is typically your government-issued ID in many countries.
Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close
enough to a lower boundary.
Yeah, it will still be hard to require 100% of packagers, but it might
be doable.
Solving this is a social problem. I'd like to remove technical
roadblocks so that we can better focus on the solutions to social
problems. Right now we aren't there on both sides.
Anyway, using a soft-based smartcard e.g. using NSS database stored on a
usb flash drive and accessible via PKCS11 could also be an option. The
problem here is to attest to a server side it is protected by the client
but this is a common problem to all different methods. Even storing a
key-pair on your hard drive would work with Kerberos PKINIT without any
problem.
> CentOS folks still use certs for their koji:
> https://wiki.centos.org/Authentication#TLS_certificate
> (and thats using the same account system/ipa servers as fedora).
>
> > I hope we can plan to work together on this improvement again, similar
> > how we did with the initial rewrite of Fedora Accounts on top of
> > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
> > perhaps CPA team could consider scheduling this effort as part of the
> > initiatives.
>
> Yeah, I would like that. Perhaps we could setup a meeting soon and
> dicuss plans? I'm open to video meeting, but we could also do IRC to
> keep things more open...
I am open to it too, may be in couple weeks or so, to allow interested
parties to prepare.
Sure. Can you schedule something when you are ready/available and we can
go from there.
Sure. I guess we can aim last week of October. I'll write up a call for
participation next week.
> > Do we have any statistics of how we stand now that Fedora Accounts is
> > deployed for more than a year and people were enabled to use 2FA tokens
> > through it?
>
> I could try and gather some. What stats would be helpfull?
A particular argument by smooge and others was arount 'passwords or
tokens being lost frequently'. I'd like to see how widespread is this
problem. Can we collect stats on amount of requests to reset passwords,
reset tokens, etc. for a period of a year or so?
We currently have 1560 tokens enrolled.
(Of course some users have more than one, but most seem to have one)
In the 1 year period from 2021-07-01 to 2022-07-01 we had 87 requests to
reset otp. Some of these were people who were confused and didn't actually
even have a otp enabled, but it's hard to count those without going
through each request.
So, it's less than 5% a year it seems like, or a request every 4days if
they were evenly spaced.
Thank you. This is actually better than I expected to see. Improving
technical measures and UX should help but there always will be something
that is harder to deal with, anyway.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
