Welcome, everyone. It's probably the first time in the last three years I actually see
this big auditorium full of people willing to hear something I'm going to rumble about.
I actually wrote a bit of a script for this, but I'm bad at memorizing those scripts, so
it will be remembering as I go, rather than seating something that I wrote about. So for
the past maybe 10 years, a team I'm a member of, we are working on a bunch of stuff related to
something that many people think is uninspiring, because it's all about the enterprise use of
Linux, which is just a done deal, right? Every enterprise uses Linux nowadays. And we kind of
look into some of the areas and choose what to work on, because there's always stuff unfinished
and needed to be working on. And suddenly there's, obviously, 10, 15 years ago, some companies from
the West Coast, they started to look into, hey, this shiny thing called the Internet and this shiny
way of having your account somewhere in the social network drive your login into your machine and so
on. And here we are, 10, 15 years after talking about doing similar thing for Linux in enterprise
environment than at home. So I will start with a bit of introduction. I'm working at Red Hat for
almost 12 years now. I'm focusing on the identity management. So basically, really running accounts
in the Linux systems. Centralized identity management is what we do. Mostly working on these
days pre-IPA. And I started with Samba 20 years ago, SSSD on the client side, MIT Kerberos for
the authentication and so on. So there's a lot of things blended together and it's really not a
single person or a single project. It's amalgamation of a lot of activities of a lot of people around
the world. This talk is a kind of a split between past contemporary things and what we see in
future or what we see now will be in future. Hopefully in February 39, if we get this through in
upstreams first and then manage to collect this all together in the distributions, which will be a
point to talk about a bit later. But in the past, we've been always getting all this stuff kind of
with a bunch of assumptions. So one of the really unspoken assumptions is that when you login into
your system, the Linux system or Windows system or so on, you don't only want to use that particular
system. Typically, you want to go beyond that system. You want to go, well, in these days, you go
onto web typically and use all these web applications, right? But before that, in office
environment, you were reaching for your nice non-working printer or you were reaching for
something to fetch files from or get your home drive and all the other stuff or play games
together with your colleagues on the local network and so on. And in many of those cases,
you needed to get through the authentication information that you provided or got at the
login time. So you needed to get this state of authentication translated or correlated into the
network onto the network services. And a typical approach that we see these days is that you
unlock your, let's say, non-session. Then there is a secrets manager, which gets your secrets
stored, unlocked using the password that you provided as a part of login. Then the passwords
from this secret store used transparently by the other applications through some common APIs,
like browsers have their own stuff. Of course, they have their own password managers and
those might be even shareable across multiple devices and so on. But it still doesn't solve
the real problem, which is when you log in into the system and you go to a specific network
face and applications, you need to do this transition or transfer the authentication state
between maybe incompatible or not well connected protocols. It is bridging that we don't really
have in place and in many applications we kind of derive it based on certain things.
Okay. In reality, it's much easier in the enterprise world because for almost 40 years
we've been dealing with something that is called Kerber's in different ways of it, which
is effectively a decoupling of the initial authentication and then requesting some authentication
tokens on behalf of you after you get this initial authentication done. That's a nice
thing. Over years Kerber's as a mechanism grown these authentication or how it's called
awkwardly in the Kerber's world pre-authentication mechanisms that allow you to use something
more than just passwords. So you can use, for example, smart cards or you can use one-time
codes, two-factor authentication mechanisms and so on to log in or provide initial credentials
to obtain the so-called ticket granting ticket in the Kerber's thing. The good part of it
is that this is exactly a way to get the transferable authentication state. Over years we added
to Kerber's ability to record how this initial state was acquired. So an application can
use an API to inquire whether this initial token was obtained with a password or with
a smart card or with some other more strong type of authentication. So it can differentiate
how to behave if, for example, application-specific policies says that you cannot use this application
if you were not using smart cards or you were not using FIDO2 tokens and so on. Then application
can inquire this information and say, yeah, you're not allowed to use this. You cannot
use sudo on these machines because you're merely used your password, that kind of thing.
And this is the thing that I was doing a lot and the one thing connected with this is that
the complexity of a typical Kerber's environment is huge. But separating the authentication
method is a nice part because it allows to decouple the other part of complexity. All
these tokens or separate devices that you can use to prove who you are and that you've
processed these credentials from the actual applications. It's really splitting up in
these two parts is what is important here because we can write applications once and
forever, at least the verification of the authentication authorization there, and deal
with the rest separately. Now this is, for example, how it looks like in a typical Kerber's
environment with free AP or with Samba AD or Microsoft's Active Directory. This is detailed
in the description from the Red Hat's Enterprise Linux Identity Management Guide. Links are
in the PDF, not just as an example of what we're dealing with. And the fun part is that
many seven years ago I've been talking in the other room in Janssen about similar things,
so how we started with this, how we started with the Enterprise Graphical Workstations
on Linux. That was, how many, 15 Fedora releases in past, 15. When I wrote that, I did not
realize that we are 37 now and it's like seven and a half years back. And almost all this
stuff already worked by that time. The smart cards were possible to use in this environment.
Of course there were some issues with the visual representation, how you choose these
smart cards and so on, but it's kind of funny that what I will be showing to you today is
kind of similar to what we did seven years ago. We fixed this problem for smart cards
eventually, together with the GNOME people. By introducing some interfaces between SSSD
and GNOME components, GDM and the other parts of the Window Manager, so that they can pick
up this information and show a nicer UI to choose who you are based on your smart card
and so on. But smart cards were the first thing we did with this passwordless authentication
because you don't need passwords anymore on this system. So what happened in these seven
years, and that's a nice period because every seven years something happens with people,
they change themselves and environment around them changes a lot. So what happened? Actually
there was change of winds and that's a fundamental one. If you remember 2015 to 2016, a typical
office environment, first there were offices where people were working every day going
into those offices and they had a network actually where those computers were connected
and enrolled into the whatever domain controllers were in those offices. It really was an environment
that was for the infrastructure for people, right? That you come, you switch in, your laptop
connected and it knows what to do. It was so to say infrastructure for people. Nowadays
there's all infrastructure in cloud and it's not for people, it's for applications. You
deploy applications somewhere in the cloud and all that infrastructure that is there
is not for you as an employee, you as someone who consumes it. You don't consume that infrastructure
anymore. In most cases, of course there are exceptions. In most cases you are consuming
the applications and applications consume that infrastructure. So if your laptop is
enrolled in something, that's most likely not the same environment as your applications
enrolled. The applications are actually consuming what? They consuming stuff like OAuth. They
get tokens, they get authorised to get tokens on your behalf from the identity provider
service that is some WAG stuff that you don't really know how is built inside in most cases
and you don't care. All you care about is that you can prove to this identity provider
your identity and for that you can use a bunch of stuff. For most of the cases on the social
networks or on a myriad of websites and so on, you don't even prove for them that you
possess certain credentials. You prove this for some identity provider that they connected
to and that something that I call bring your own authentication. So you connect your account
in something to your social network account and you prove to the social network that you
are who you are and then that social network IDP issues talking to that site where you
want to be. That's essential, bring your own authentication to that site. The site doesn't
really care how you authenticate it to the social network, how you prove yourself. And
in fact what becomes out of it is all infrastructure around OAuth and all IDC is a part of it is
built around I have a browser and this browser is everything I need. There are radio acts
between different components and websites. They talk to each other on your behalf. So
this is kind of a new mainframe where everything runs. So you still need a network access for
this to work. And here we get back to the 2016. In 2016 one of the biggest issues we
were identified at that point for enterprise workers was everyone goes into business trip,
goes into the hotel and every single hotel has captive portal on their Wi-Fi. So in order
to log in into your machine using your credentials you have to solve a problem of solving captive
portal before you log in into the machine. The fun part is that we never solved this
problem at all. Instead of solving this problem we basically say to ourselves let's remove
our machines from the corporate environment, right? Decouple machine from the environment
rather than solving the problem. Maybe this is a good solution. Maybe not. Because right
now to solve, to get this authentication again working for us we need to run browser before
we log in again. And running browser before you log in in titles running insecure unknown
executable which is JavaScript code with the access to your hardware which is your at least
screen and GPU and so on because that's what the browsers are requiring to do this stuff.
So that's still the problem to solve and of course some of these problems might be solved
but some of these problems might be, hey, move the way. So almost everyone has a phone.
So this is somewhere I can run a browser instead of my laptop. So maybe I can run the authentication
and authorization process on this separate device instead of running it on my laptop
when I try to log in. It's kind of getting around the problem but maybe all the problems
are like that. Get around them, roughen them, solve them directly. And in some cases this
is not even a problem. For example, if you want to log in over SSH and you're already
logged into your workstation then launching a browser on your already logged in workstation
is easy, right? You just need to have a URL to get into. So let's try, I hope I will show
this. Let's try a demo. So here I'm trying to SSH into some machine and on the left side
from you, I have an IDP based on the key clock, open source project. And this user, it doesn't
have the security key associated with it. Now I'm associating. So basically I'm taking
this kind of token and connecting it with this user. Okay? I have this token associated
somewhere there. And now I can log out of my IDP just to make sure that I don't reuse
the same session that I obtained with the password, right? So now I'm trying to SSH
and I'm presented with a message that says, okay, authenticate against this browser somewhere.
So I have a browser. It's handy. I'm getting, I'm using the security key to actually authenticate
instead of the password. I authenticate it into the system. Now the system says, do you
authorize this access? Yes, I authorize this access and load it into the system. But a part
of this authorization is that I'm getting Kerberos ticket. Kerberos ticket issued to
me by my infrastructure. And now this Kerberos ticket can be used for, well, anything. Anything
that's allowed there within this Kerberos environment. So I can SSH with this Kerberos
ticket further. I can mount NFS or Sambo, something shares, get access to files. I can use this
Kerberos ticket to sudo into the system itself. There is, since last year, or actually 2001,
there is a POM module as a part of SSSD, POM, SSS, GSS. This module actually checks that
you have active Kerberos ticket and its properties are good enough to access POM services. So
you can configure, for example, sudo to say that if you have Kerberos, active Kerberos
ticket, obtained with this IDP authentication or smart card, then you can use sudo rules
on this machine. Which rules is separate from this, but you can get access to sudo with
it. You don't have password. You never had password in your system. And the password
may be existed somewhere in the IDP, in this key clog thing, or in GitHub, or GitLab, or
Google for your company, or Azure for your company, or your own key clog stuff. But the
rest will work the same, regardless of how you get there. So it's a bit complex in terms
of how this is implemented and how it goes. But at the core of it is we split the process
in two parts. There's initiating part, which in this case is the running on the server
I tried to log in. There is a part that actually verifies that your IDP authorized access,
which is running on the Kerberos key distribution center part, so Kerberos server side. And
then there is a client, which is in our case SSH, trying to connect to the SSH server,
which initiates process. And of course, there is a browser that you run somewhere. You sold
that URI there, probably to use a phone to access that URI. You probably want to have
a QR code instead of the URI, or in addition to the URI. This is one easy thing that we
need to implement to make it easier. But also, it will become probably a mandatory part if
you want to integrate this with the graphical login into the system, because you cannot
run browser yet. But sure, you can show the nice picture that you can access from your
phone or other device. And you will need something like that for the past keys existing only
on your phone, the soft FIDA 2 tokens that both Apple and Google are eager to push to
us these days. So effectively, the same thing works with the FIDA 2. In fact, the demo that
I showed was FIDA 2 token, because the IDP side was configured to use FIDA 2 or Web
Wolf token instead of password or smart card or OTP, whatever is there. So we already can
do this. It's already, in fact, all the tests that I ran, it's Fedora 37, the one that's
already released last November last year. So this passwordless login to the Linux console
works on Fedora, works on RHEL 8.7.9.1, and a client side of it works on Ubuntu 22.10,
because they have this new SSSD version that supports this stuff. Okay. So if I want to
do this with the other services, let's hope I can get another demo. How I can switch to
the next one, huh? Use it just a second.
Okay. So this is basically exactly the same demo, just using, instead of SSH, I'm using
VLOG. VLOG is just a normal application that uses PAM, Plugable Authentication Mechanism
Module, to lock your system. So typically what happens is that you lock your console,
and then you have to provide a password. VLOG doesn't know anything about all this stuff,
but it works because we use the standard APIs there. And in this case, I don't need to provision
the token, obviously, because it's already provisioned, but I can use it to log in into
the VLOG application. This goes just transparently, maybe awkwardly because of the URLs and not
nice UIs and so on, but still it's there. The most important part here is that in order
to all this get work, and we have to have a network and service, this IDP thingy, how
we can get without it. Well, FIDAR2 has this ability to work locally and not really through
the web stuff. So we can run this authentication locally. And all these tokens that Ubico and
all of this is token EU or some others, they usable in the isolated environment as well.
So we can actually run it. So I got one small demo with this to, let's hope I get this started.
This is recorded with my phone camera because I needed to actually show you that I pressed
something on the screen. So this screen is locked, right? And now I'm trying to log in
into that screen. And it asks me to insert this passkey device. So I'm inserting it in
and you can see that it doesn't actually show you the full message that is shown there.
The part of the message says and press enter before it goes further. So when I press enter,
it tries to communicate with the device. It blinks to me and then I have to press a test
that I physically present at the device to log in it. And after that, I'm unlocking
the same way as with VLog or SSH through the palm. I'm unlocking this. This was my presentation
this morning at the security dev room about the same thing. Now, if we go logically further,
this is working actually by the way. I cannot show it on this laptop because as soon as
I lock my screen to unlock, the video stream through HDMI will get disconnected and we
will have to wait another five minutes to get my screen working back. So you wouldn't
see this on the screen. So believe my camera. Now, how we can combine this? Logging in locally
with the FIDO2 token is effectively, it gives me a login into the system. But the very first
thing, the same problem that I discussed in the beginning applies here. How I transfer
this authentication state that I used this passwordless device to log in to other applications?
Well, in enterprise environment, whatever we call enterprise environment, for me for
the last 10 years or so, enterprise environment is my home environment because I run what
I develop, free IPA in my, as my home authentication service. I simply need to transition from
this FIDO2 token authentication to Kerber's ticket using it, right? Sounds simple. Yes,
it's also a bit of arrows and lines and so on, but it's pretty much in line with this
one. It's just the question of who is communicating with whom to prove that the possession of
credentials is the real one. Okay. Unlike the previous one, I cannot show a demo of
this one because we are at the point where maybe in two weeks we will complete this implementation.
And of course, the amount of bugs to find and fix will get this probably delayed until
Fedora 39 or so. But I really hope to get this working by that time, which is by the
way just how many? Seven, nine, nine months away. Sounds a nice number. So that's not
everything, of course, because, well, it's only an infrastructural part of it. To get
it usable and not to the point that users will trash their laptops because they cannot
read the message. Imagine this is just a simple insert your passkey device. What if this was
authenticate against these URL, HTTPS, something that can't even fit into this box? That's
the situation right now. So we need to fix this with, in this case, it's a GDM, of course,
this is the GNOME display manager. For the login, we need to fix this. And we started
talking with the GDM developers, and there is some common understanding of what to do
similar to what we did with the smart cards. The nice part of it is that it's mostly about
a protocol of communicating between the PAM service, in this case, SSD, and the display
manager through the environmental variables within the process. So SSD can tell that I'm
now using this type of passwordless authentication. Please switch to this visualization of it.
So we kind of can make it this way that it works for GNOME, but it's also usable for
others. And here I come to the point of effort across multiple projects. So you can do this
with GNOME, but then what to do with GDE, what to do with XA, XFAC, and others. There's
a need to agree on something. We can agree on APIs, we can agree on protocol driving semantics
behind this, but somebody needs to implement all these pieces in the end. This is a common
effort as a community. It's not just one company or one developer crazy enough can drive and
write all this code and get it. We as a community need to work together to get this done. And
of course, this is just a top of the iceberg. This bunch of work needs to be done on the
distribution level to make it usable for cleaning installations, for example. If I want to
use this type of the key, if I go to keys, for example, for the login into machine, I'm
sure probably want to use it also to provision encryption of my disk. And this is already
possible with system D supporting configuration of lock devices with the FIDO2. In all contemporary
distributions, system D already compiled with support for FIDO2. It's a matter of configuring
them, right? It's the matter of configuring other services to reuse all of this. But I
don't think as much as I like wiki pages that describe how to do this in multiple articles,
I don't think this is what we should be doing. It's the distribution level job to polish
or add this kind of polish. Again, as a community of distribution developers, in Fedora, in
Debian, in others, in Arc, we need to focus on this kind of polishing. When all these
pieces ready, sure, someone will be faster with the releases and polishing of it. But
in the end, we as a community, we as community of developers, users, we are users themselves,
even if we are, we know how this stuff works. It doesn't mean that we tolerate how badly
it's integrated. So that's my message here. We need to work as a community to bring it
all to us, to be pleasant to work with. And with this one, I guess I'm even on time. Thank
you.
My question is about the two factor authentication when there is a password and a security key.
Do you know why in all the work flow the password is first and then the security key? Whereas
it likes to me that the security key is the strongest part, and it should be better to
first press the button of the key and then enter the password. Is there some movement
to change the current way of doing things?
The question is whether using password and second factor and so on can be one of the
ways of doing it. And is there an activity to make it better, let's say this way? Yes
and no. It depends on what we define as the first factor and second factor. One of the
driving factors behind password less work in the last 10 years or so across the industry
is the tightening of requirements from the government, specifically from the U.S. government.
The U.S. government issued a so-called zero trust memorandum last year for urging governmental
organization to move by end of fiscal year 2024 to move to password less authentication.
This means that they have smart cards already, so that's solved. But they specifically name
web often 5-2-2 as one of the alternatives to smart cards. And in fact, all of these
things they have PIN associated with this, which can be looked as a kind of first factor.
But it's not the first factor as we understand it. It's a first factor to unlock hardware
rather than unlocking some factor in software. So this is the thing which drives some of
this work, not necessarily for us but for many others already. And I think there is
a value in staking factors. The question is in which environments you want to use them
and so on and configure it this way. Certainly there is already a mechanism to enable it.
For example, PAM already is staking. So technically you can stack multiple PAM authentication
modules in the same configuration for VLOC or GDM or something and say always enter three
passwords from different sources. That already would be multi-factor, multi-password authentication.
Or one of them this and the other one is the password and the third one is phase of the
moon and so on. So you can get that stuff already. It's the question of adopting to a specific
environment where this makes sense. I have not seen multi-password in the traditional
kind of environments yet. But if we do something like integration with the identity providers
like I show it in the demo, that gives you possibility to move this check away into let's
say keyclog. Keyclog actually has ability to ask a password, OTP and the web often at
the same time. So you can configure that already. Again, the question is in which direction
you want to focus this. Maybe not adding into SSSD or some specific PAM module but instead
adding into more flexible and more controllable source. Any other questions?
Yes, here. So you were talking about how can distributions and desktop managers contribute
to get like a unified interface and I recently come to a project called XTG credentials portal
which tries to specify a standardized debas interface for interacting with web often credentials
such that different KDE and GNOME and stuff can hook into this. I was wondering whether
you were aware of this project and if that would be a good place to maybe start trying
to collaborate on a unified interface. So the question is am I aware of the projects
like XTG credentials that tries to specify or unify access to the credentials for things
like I think it's for the containerized environments, desktop applications running in flat pack
and so on. Yes, I am aware and that's one partial thing that I mentioned about the parallel
effort there but it's not for the logging, it's for the reuse of the credentials in the
browser or relaying party outside of the container so that you can isolate direct access. That's
very important but it's a bit different layer and it's the layer that we will eventually
need to reuse if we want to do this transferable state of authentication between different
places without caregivers. Yes, we will have to work with them or Dave with us or everyone.
Yes.
Hello. So I use ED25519 security keys which SSH supports and it's really simple so I just
generate a key and I can use it and my SSH demon supports it and I don't really need to
run any services and I need to use Kerberos. How do we get to a world where everything
is that simple?
So the question is why do I need all these things if my SSH keys work fine with the hardware
based tokens, X549 and basic certificates and so on. The answer is simple. It's not
an answer for all use cases. You cannot authenticate with these tokens and these keys to, for example,
file services. You cannot use them to authenticate to NFS. You cannot use them to authenticate
to SMB or other resources. Needs are different, use cases are different. All of these things
does not replace SSH keys and SSH keys do not replace this one. They exist in parallel to
each other because if you start using FIDO2 tokens, you wouldn't be using them exactly
the same way on SSH level as well because SSH will need to generate their own keys based
on the same, use of the same hardware but different protocol specific and application
specific thing. And this is where the program really comes in. You can find use cases where
existing functionality is perfectly usable and secure and attainable but it's not transferable
to the other systems and other protocols. That's the problem we try to solve. So it's
more amending rather than displacement. Hello. Hello. And thanks for the talk. My question
is if I'm a very, very bad person, I want to break this system and steal the Kerberos
ticket authentication, for example, what's the easiest way I can do it? So the question
is how to steal Kerberos ticket in the Linux environment in the easiest way despite all
the protection mechanisms we want to add. I preferably answer what mechanisms we have
so that you may reconsider your activities. So in comparison, Microsoft some time ago
added a virtualized slice where they store all the credentials so you do not have access
to that slice. It's running literally not as a container, it's like a VM separated from
the actual system where they handle all the security credentials and so on. And you cannot
easily store that from the memory of the applications that try to load this stuff. On Linux side
at that point we had a project called GSS proxy. The GSS proxy is a daemon that runs in separate,
typically on the root, and it interjects into GSS API, hence the GSS proxy. GSS API operations
and interposes access to all Kerberos crypto material. So when you are a service like
HDTPD or NFS, you want to have access to the Kerberos key tab so that you can authenticate
clients coming to you and get access to it, or your IMAP or send mail or something. And
GSS proxy basically removes access to the key tabs, removes access to credential cache
that you use. They are in separate process. So now if you're broken into NFS server like
Ganesha or even the kernel, well, kernel one is probably easier target, right, if you happen
to find a bug that allows to exploit it. But you're probably not a Linux Torvalds anymore
and it's not 1994 where he found NFS problems to hack into and get the data out. Out of
NFS. So typically this privilege separation between the processes works fairly well.
If you're root, of course, you get what you get. In that case, there's some number of
ways of preventing root running processes from accessing the capabilities on the kernel
level. And on typically still this is an operation that should probably be multi-layered. Like
you have to use kernel capabilities, then you have to use the file system level capabilities
then as a Linux or app armor to prevent other kind of access things. But basically with
the GSS proxy we get isolation on this level and also we get the content of the credential
caches encrypted. So you can store or you can steal credential cache if you get access
to that. But it will be encrypted with temporary key that exists only until GSS proxy runs.
So even if you steal it, you cannot really use that one. The other part is that there
are credential cache collection types that do not allow direct access to the credential
cache. So for example a key ring, kernel key ring where you can store and tighten it fairly
tight so that the application doesn't get these keys out. The other one is KCM which
is also a separate process accessible over the Unix domain socket. You don't get direct
access to the files either. So there are some mechanisms. They are not so dramatic as in
Windows case where they run it in completely different VM isolated on a hardware level.
But we get fairly far away. I've seen people trying to decode the KCM databases but that
presumes that they get access to the physical root partitions so they can read the actual
files from the KCM back store. But of course that if you're root, if you haven't access
to the root partition, your game is lost in most cases.
Alexander, many thanks for your interesting talk to give the community.