Passwordless Linux - where are we?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61765 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
James Waddell Alexander IISoftwarePrincipal idealAuthenticationIdentity managementFocus (optics)Enterprise architectureKerberos <Kryptologie>FreewarePasswordLatent heatMechanism designLoginPhysical systemBitMultiplication signService (economics)Amalgam (chemistry)Heegaard splittingIdentity managementClient (computing)Scripting languageInternetworkingEnterprise architectureSimilarity (geometry)SoftwareInformationIntegrated development environmentLoginMultilaterationWindowPoint (geometry)AuthenticationProjective planeState of matterLocal area networkOffice suiteGame theoryWeb applicationCentralizer and normalizerDiagramComputer animation
05:15
Latent heatMechanism designAuthenticationLoginKerberos <Kryptologie>Computer networkPasswordPersonal digital assistantUniform convergencePlastikkarteData storage deviceEnterprise architectureCommunications protocolDifferent (Kate Ryan album)Kerberos <Kryptologie>Heat transferState of matterPhase transitionSoftwareCartesian coordinate systemDescriptive statisticsAuthenticationWeb browserLink (knot theory)Flow separationMereologyInformationMechanism designIntegrated development environmentFormal verificationAuthorizationToken ringPasswordLoginHeegaard splittingLatent heatPhysical systemFreewareComplex (psychology)Computer animation
10:25
Kerberos <Kryptologie>AuthenticationBeta functionPasswordTime domainControl flowSingle-precision floating-point formatVirtuelles privates NetzwerkComputer networkSystem programmingIntegrated development environmentEnterprise architectureFreewareMathematicsWeb browserMainframe computerAuthorizationBridging (networking)Web portalInternet service providerIdentity managementLoginMenu (computing)LaptopContent (media)Information securityIdentity managementWebsitePoint (geometry)Component-based software engineeringMereologyDifferent (Kate Ryan album)Virtual machineWorkstation <Musikinstrument>PlastikkarteIntegrated development environmentOrder (biology)Web browserEnterprise architectureAuthenticationTouchscreenCartesian coordinate systemGame controllerMathematicsOffice suiteNeuroinformatikPhysical systemWindowPasswordInterface (computing)Internet service providerLaptopSimilarity (geometry)Token ringMainframe computerCASE <Informatik>Computer animation
17:49
Web browserRemote Access ServiceDemo (music)Physical systemMechanism designAuthenticationKerberos <Kryptologie>AuthorizationAuthenticationWeb browserAuthorizationUniform resource locatorLaptopWorkstation <Musikinstrument>Process (computing)Computer animation
18:46
InformationInformation securityControl flowPasswordTrailSign (mathematics)AuthenticationFormal verificationToken ringAssociative propertyKey (cryptography)Open sourceProjective planeInformation securityComputer animation
19:27
AuthenticationPasswordFormal verificationCodeSign (mathematics)Information securityInformationControl flowTrailLoginPrincipal idealPermanentVirtual machineRule of inferenceKerberos <Kryptologie>Physical systemMessage passingIntegrated development environmentPasswordAuthenticationShared memoryKey (cryptography)MereologyInformation securityWeb browserCategory of beingPlastikkarteModule (mathematics)Authorization
22:10
Kerberos <Kryptologie>PasswordProcess (computing)Term (mathematics)MereologyCore dumpBitComplex (psychology)AdditionServer (computing)CASE <Informatik>Key (cryptography)Message passingDistribution (mathematics)Token ringQR codePhysical systemLoginWeb browserKerberos <Kryptologie>Computer animation
24:03
LoginAuthenticationToken ringVideo game consoleRevision controlClient (computing)Video game consolePasswordDemo (music)Software testingLoginPlastikkarteComputer animation
25:01
Principal idealWorld Wide Web ConsortiumAuthenticationLoginMaxima and minimaWeb browserInformationSoftware testingComputer wormDemo (music)2 (number)Computer animation
25:54
Information securityAuthenticationPrincipal idealDefault (computer science)World Wide Web ConsortiumLoginCartesian coordinate systemStandard deviationPhysical systemDemo (music)Password
26:33
Default (computer science)Software testingPrincipal idealSign (mathematics)Service (economics)Demo (music)Cartesian coordinate systemUser interfaceUniform resource locatorToken ringWeb 2.0Order (biology)AuthenticationMereologyUsabilitySoftwareComputer animation
27:41
Drill commandsVideoconferencingTwin primeInformationNewton's law of universal gravitationMountain passDemo (music)SoftwareJames Waddell Alexander IIPrincipal idealDemo (music)TouchscreenMereologyMessage passingInformation securitySoftware testingPresentation of a groupComputer animation
28:53
Demo (music)Kerberos <Kryptologie>Local ringSimilarity (geometry)DisintegrationTouchscreenEnterprise architectureLine (geometry)Integrated development environmentBitArrow of timeAuthenticationCartesian coordinate systemPhysical systemInternet service providerStreaming mediaCombinational logicState of matterLoginGroup actionLaptopComputer animation
30:31
Error messageKerberos <Kryptologie>Token ringLoginAuthenticationVideo game consolePasswordService (economics)Demo (music)Hill differential equationDisintegrationIntegrated development environmentDistribution (mathematics)Computer-generated imageryDevice driverLine (geometry)SoftwareIntegrated development environmentAuthenticationPlastikkarteInternet service providerPasswordFreewareMechanism designService (economics)LoginMultiplicationNumberPoint (geometry)Software bugIdentity managementSoftware developerInsertion lossElectronic visual displayLatent heatLaptopMessage passingMereologyWeb 2.0Communications protocolConfiguration spaceSemantics (computer science)Different (Kate Ryan album)Projective planeType theoryVisualization (computer graphics)Variable (mathematics)Process (computing)INTEGRALDirection (geometry)Multiplication signKey (cryptography)Open sourceDistribution (mathematics)Web pageEncryptionMiniDiscLevel (video gaming)Demo (music)2 (number)Stack (abstract data type)Module (mathematics)Computer hardwarePhysical systemExterior algebraPersonal identification numberSelf-organizationInformation securityComputer animation
40:49
Device driverComputer-generated imageryLimit (category theory)Link (knot theory)EmpennageMaterialization (paranormal)Internet service providerDemonCryptographyProxy serverCache (computing)EmailKey (cryptography)Client (computing)File systemSoftware bugSinguläres IntegralKerberos <Kryptologie>Domain nameRootContent (media)NumberService (economics)Flow separationInformation securityProcess (computing)Token ringWindowComputer fileNetwork socketCartesian coordinate systemMechanism designRing (mathematics)CASE <Informatik>Level (video gaming)Projective planePartition (number theory)PhysicalismOperator (mathematics)Computer hardwareGame theoryMobile appWeb browserIntegrated development environmentWeb 2.0AuthenticationIdentity managementType theoryPhysical systemMereologyFunctional (mathematics)Different (Kate Ryan album)Interface (computing)Standard deviationHeat transferState of matterParallel portMultiplication signCommunications protocolSemiconductor memoryProgram slicingComputer animation
50:46
Computer-generated imageryDevice driverComputer animationProgram flowchart
Transcript: English(auto-generated)
00:06
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.
00:23
I actually wrote a bit of a script for this, but I'm bad at memoizing those scripts. So it will be remembering as I go, rather than seeking something that I wrote about.
00:43
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,
01:01
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 is always
01:20
stuff unfinished and needed to be worked 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
01:45
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 things for Linux in the enterprise environment and at home.
02:01
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.
02:24
Centralized identity management is what we do. Mostly working on, these days, pre-IPA. I started with Samba 20 years ago. SSDE on the client side, MIT Kerberos for the authentication
02:44
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 an 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
03:08
and what we see in future, or what we see now will be in the future. Hopefully in Fedora 39, if we get this through in upstreams
03:23
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
03:41
with a bunch of assumptions. So one of the really unspoken assumptions is that when you're logging into your system, be it Linux system or Windows system or so on, you don't only want to use that particular system.
04:01
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. But before that, in office environment, you were reaching for your nice non-working printer,
04:21
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.
04:42
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
05:02
onto the network services. And a typical approach that we see these days is that you unlock your, let's say, gnome session. Then there is a secrets manager, which gets your secret store unlocked using the password
05:24
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.
05:42
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 phase and applications,
06:02
you need to do this transition, transfer the authentication state between maybe incompatible or not well-connected protocols. It is bridging that we don't really have in place.
06:20
And in many applications, we derive it based on certain things. In reality, it's much easier in the enterprise world because for almost 40 years, we've been dealing with something that is called Kerberos
06:40
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 got this initial authentication done.
07:01
And that's a nice thing. Over years, Kerberos, as a mechanism, grown these authentication, or how it's called awkwardly in the Kerberos world, pre-authentication mechanisms that allow you to use something more than just passwords.
07:21
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 the initial credentials to obtain the so-called ticket
07:43
grant and ticket in the Kerberos theme. So the good part of it is that this is exactly a way to get the transferable authentication state. Over years, we added to Kerberos ability to record how this initial state was acquired.
08:02
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.
08:24
So it can differentiate how to behave if, for example, application-specific policy says that you cannot use this application if you were not using smart cards, or you were not using FIDO2 tokens, and so on.
08:41
Then application can inquire this information and say, yeah, you are not allowed to use this. You cannot use sudo on these machines, because you merely used your password, that kind of thing. And this is the thing that I was doing a lot.
09:02
And the one thing connected with this is that the complexity of a typical Kerberos environment is huge. But separating the pre-authentication method is a nice part, because it allows to decouple the other part of complexity, all these tokens
09:25
or separate devices that you can use to prove who you are and that you possess these credentials from the actual applications. It's really splitting up in these two parts is what is important here.
09:40
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 Kerberos environment with free AP
10:03
or with Samba AD or Microsoft Active Directory. This is a detailed description from the Red Hat Enterprise Linux Identity Management Guide. Links are in the PDF, but just as an example
10:22
of what we are dealing with. And the fun part is that seven years ago, I've been talking in the other room in Janssen about similar things. So how we started with this, how
10:40
we started with the enterprise graphical workstations on Linux. That was, how many, 15 federal releases in past, 15. When I wrote that, I did not realize that we are 37 now
11:00
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 we choose these smart cards
11:21
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
11:42
components, the 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.
12:02
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
12:21
something happens with people. They change themselves, and the environment around them changes a lot. So what happened? Actually, there was a change of winds. And that's a fundamental one. If you remember 2015, 2016, a typical office environment,
12:41
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 whatever the main controllers were in those offices. So it really was an environment
13:01
that was for the infrastructure for people, that you come, you switch in, your laptop connected, and it knows what to do. It was, so to say, infrastructure for people. Nowadays, this whole infrastructure in cloud,
13:23
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.
13:41
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,
14:02
that's most likely not the same environment as your applications enrolled. The applications are actually consuming what? They're consuming stuff like OAuth. They get tokens, they get authorized to get tokens on your behalf from the identity provider
14:23
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.
14:40
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.
15:01
And that's 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
15:21
issues token to that site where you want to be. That's essential to bring your own authentication to that site. The site doesn't really care how you authenticated to the social network, how you prove yourself. And in fact, what becomes out of it is all infrastructure around OAuth and OIDC as a part of it
15:47
is built around I have a browser, and this browser is everything I need. There are redirects between different components and websites. They talk to each other on your behalf. So this is kind of a new mainframe
16:03
where everything runs, right? So you still need a network access for this to work. And here we get back to the year 2016. In 2016, one of the biggest issues we were identified at that point for enterprise workers
16:23
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 onto your machine using your credentials, you have to solve a problem of solving captive portal before you
16:41
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
17:00
rather than solving the problem. Maybe this is a good solution, but 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 entitles running insecure unknown executable, which
17:26
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.
17:44
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.
18:03
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.
18:22
Get around them, rough 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.
18:40
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.
19:04
And on the whatever, 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.
19:21
So basically, I'm taking this kind of token and connecting it with this user. 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.
19:42
So now, I'm trying to SSH, and I'm presented with a message that says, OK, 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.
20:02
I have authenticated into the system now. The system says, do you authorize this access? Yes, I authorize this access and logged into the system. But a part of this authorization is that I'm getting Kerberos ticket. Kerberos ticket issued to me by my infrastructure.
20:24
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
20:42
get access to files. I can use this Kerberos ticket to sudo into the system itself. There is, since last year, or actually, 2001st, there is a PAM module as a part of SSSD, PAM, SSS, GSS.
21:05
This module actually checks that you have active Kerberos ticket. And its properties are good enough to access PAM services. So you can configure, for example, sudo to say that if you have Kerberos,
21:23
active Kerberos ticket, obtain it 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.
21:41
You never had password in your system. And the password maybe existed somewhere in the IDP in this kick log thing, or in GitHub, or GitLab, or Google for your company, or Azure for your company, or your own kick log stuff.
22:04
But the rest will work the same, regardless 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.
22:26
There's initiated 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
22:41
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.
23:01
All right. You saw 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 easier kind of thing that we need to implement to make it easier.
23:23
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.
23:44
And you will need something like that for the pass keys existing only on your phone. And the soft FIDO2 tokens that both Apple and Google are eager to push to us these days.
24:03
So effectively, the same thing works with the FIDO2. In fact, the demo that I showed was FIDO2 token because the IDP side was configured to use FIDO2 or WebAuth token instead of password or smart card or OTP, whatever is there.
24:26
So we already can do this. It's already, in fact, all the tests that I ran, it's FIDOR 37, the one that's already released November last year.
24:41
So this passwordless login to the Linux console works on Fedora, works on RHEL 8791. And a client side of it works on Ubuntu 22.10 because they have this new SSSD version that supports this stuff.
25:02
So if I want to do this with the other services, let's hope I can get another demo.
25:21
How I can switch to the next one? I'll use it in just a second.
25:58
So this is basically exactly the same demo.
26:04
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,
26:22
and then you have to provide the 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.
26:40
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.
27:02
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 thing, how we can get without it? Well, FIDO2 has this ability to work locally and not really through the web stuff.
27:22
So we can run this authentication locally. And all these tokens that Yubico and, well, this is token EU or some others, they're usable in the isolated environment as well. So we can actually run it.
27:42
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.
28:01
So the 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.
28:22
The part of the message says 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.
28:41
And after that, I'm unlocking the same way as with Vlog or SSH through the PAM, 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,
29:04
this is working actually, by the way. I cannot show you 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
29:20
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? Okay, 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
29:43
that I discussed in the beginning applies here. How I transfer this authentication state that I used the passwordless device to log in to other applications. Well, in enterprise environment, whatever we call enterprise environment,
30:03
for me, for the last 10 years or so, enterprise environment is my home environment because I run what I develop, free IPA as my home authentication service. I simply need to transition from these FIDO2
30:23
token authentication to Kerberos 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.
30:41
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
31:00
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,
31:21
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 the infrastructural part of it.
31:44
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.
32:00
What if this was authenticated against this 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.
32:23
For the login, we need to fix this. And we started talking with the GDM developers and there's 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
32:41
the protocol of communicating between the PAM service, in this case, and the display manager through the environmental variables within the process. So SSSD can tell that I'm now using this type of passwordless authentication.
33:01
Please switch to this visualization of it. So we kind of can make it this way that it works for GNOME, but it also usable for others. And here I come to the point of effort across multiple projects. So you can do this with GNOME,
33:22
but then what to do with KDE? What to do with 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
33:41
all these pieces in the end. This is a common effort, us 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.
34:05
And of course this is just at top of the iceberg. There's a bunch of work needs to be done on the distribution level to make it usable for clean installations, for example.
34:23
If I want to use this type of the key, FIDO2 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
34:41
supporting configuration of lock devices with the FIDO2. In all contemporary distributions as system D already compiled with support for FIDO2. It's a matter of configuring them, right?
35:01
It's the matter of configuring other services to reuse all of this. But I don't think, as much as I like Reiki 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
35:24
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.
35:41
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 know how this stuff works. It doesn't mean that we tolerate
36:05
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.
36:25
Thank you. My question is about the two-factor authentication
36:40
when there is a password and a security key. Do you know why in all the workflow, the password is asked 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
37:02
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,
37:25
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
37:41
is the tightening of requirements from the government, specifically from US government. US government issued so-called zero trust memorandum last year for origin governmental organization to move by end of fiscal year 2024
38:04
to move to password-less authentication. This means that they have smart cards already, so that's solved. But they specifically name WebAuth and FIDO2 as one of the alternatives to smart cards.
38:22
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.
38:44
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
39:02
you want to use them and so on and configure this this way. Certainly, there is already a mechanism to enable it. For example, PAM already staking. So technically, you can stack multiple PAM authentication modules in the same configuration
39:23
for V-lock or GDM or something and say always enter free passwords from different sources. That already would be a multi-factor, multi-password authentication. Or one of them this and the other one is the password and the third one is face of the moon and so on.
39:43
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.
40:00
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 key clock. Key clock actually has ability to ask a password or TP and the web auth at the same time.
40:22
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.
40:43
Okay, 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 bumped into a project called XTG credentials portal, which tries to specify
41:02
a standardized D-Bus interface for interacting with web auth and credentials such that different KTE and Nome 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 on trying to collaborate on a unified interface.
41:21
Yeah, 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 Flatpak and so on.
41:43
And yes, I am aware, and that's one partial thing that I mentioned about the parallel effort there. But it's not for the login. 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.
42:02
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 Kerberos.
42:20
Yes, we will have to work with them, or Dave with us, or everyone, yes. Hello, so I use ED25519 security keys,
42:43
which SSH supports, and it's really simple. So I just generate a key, and I can use it, and my SSH daemon supports it. And I don't really need to run any services. I don't need to use Kerberos. How do we get to a world where everything is that simple?
43:01
So the question is, why do I need all the things if my SSH keys work fine with the hardware-based tokens, X549-based certificates, and so on? The answer is simple. It's not an answer for all use cases.
43:23
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,
43:41
all of this thing 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
44:03
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 problem really comes in. You can find use cases where existing functionality
44:23
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 displacing.
44:59
Hello, hello, and thanks for the talk.
45:03
My question is, if I'm a very, very bad person and 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 a Kerberos ticket in the Linux environment in the easiest way,
45:22
despite all the protection mechanisms we want to add. I'd probably answer what mechanisms we have so that you may reconsider your activities. So in comparison, Microsoft some time ago
45:42
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
46:01
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.
46:22
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,
46:41
and interposes access to all Kerberos crypto materials. So when you run a service like HTTP D or NFS, you want to have access to the Kerberos key tab
47:00
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
47:22
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.
47:43
But you're probably not in Linux Torvalds anymore and it's not 1994 where he found NFS problems to hack into and get the data out of NFS. So typically this privilege separation
48:02
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
48:22
from accessing the capabilities on the kernel level. And on typical steel, 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
48:41
than as a Linux or app armor to prevent other 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.
49:01
So you can store or you can steal credential cache if you get access to that. But it will be encrypted with a 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
49:24
collection types that do not allow direct access to the credential caches. So for example, a kernel key ring where you can store and tighten it fairly tight so that the application doesn't get these keys out.
49:42
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
50:02
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
50:22
from the KCM back store. But of course, if you're root, if you have an access to the root partition, your game is lost in most cases. Yep. Alexandra, many thanks for your interesting talk to give the community.
50:40
Thank you very much.