So now the mystery is going to talk about the response, the mystified and beyond.
So thank you for coming to this session.
I didn't expect to mention open message during this talk, but we will see how things will go.
I really think that so many people would be interested in this pun thing, certainly not me.
Well, first I would like to ask yourself how many times today did you use authentication of some kind of sword?
My bet is you didn't count because it's ubiquitous nowadays.
Unless you're debugging something which is not likely, today is not the best day for debugging.
Well, as we saw just now.
So today I'll be talking about whatever remains to be demystified about palm.
Shortly we'll see what is it and why it evolved this way.
I'll be talking about core concepts, a lot about configuration things, about the frozen stack thing.
About recently recent developments and what could happen in the future, maybe possibly.
And if time permits, a bit more about troubleshooting in best practices.
So what is palm?
It's a framework framework of shared libraries and plug-able models which are also shared objects.
It's all configured and very flexible configuration leaves in a certain directory.
And the purpose of this is to enable system means to choose how various applications and solve them the system authentication users.
Without need to recompile or attach the applications themselves.
And to switch between these authentication mechanisms without touching the applications.
So in the very beginning, before it is scheduled, things were very simple and there are no need to do anything like what we are doing today.
Like just two functions want to obtain the password entry and another to check the password.
And everything was simple.
Later when the shadow concept was introduced, things started to become complicated.
Like when you think about adding, for example, cable support to every application, it becomes a peculiar task.
So that resulted to inconsistency when one application used one implementation or one variation of authentication and another used another one.
These, the situation could easily end in the past, easily run out of control.
So with a centralized library that every application uses,
you can achieve all these charges like consistency and control all the system.
So how bomb organized things?
It divides everything into four management groups.
The authentication that answer the question is the user, the one who says his or she,
the account management that answers the question whether the user is allowed to use that particular service right now.
The session management, that setups whatever is needed for the session and then things up.
And if there is a need for password management, there is a password management.
Like there are explicit tools to change passwords and sometimes some models may say that password is expired and it has to be changed before the authentication proceeds.
So let's go through all of these groups.
The classic way of the authentication is the password indication.
Like, for example, the traditional Pambianic module that indicates against the the question start for each either in an it is a shadow file.
They could be like, relating against a dongle or biometrics scan or like remote server or any kind of like.
There are a few modules for one time passwords.
Well, most of them are out of few models, but some are very traditional like Pambianic city is fetched along with Linux power itself.
Account management like it also Pambianic does something other kind like it checks the password expiration.
There are various other.
The reasons to to do accounting like whether whether the account is not due to too many legato attempts could be time based restrictions and like service based and whatever.
In management, a lot of models also like standard and out of three, like standard modules are the model that set up kernel keyring.
Traditional resource limits, UMask home deacucation for remote dedicated users.
Well, the out of three system D module that register the session against the in the login.
And a password management.
Let's usually two things.
First, the checks that the password meets the quality rules and there are two out of three models for this.
Checking whether it like other police rules like with pv history that checks against takes.
Pass with a used for this user in the past and actually changing the password.
These are traditional models, but out of few models are doing the same thing for for the remote service.
So how it is implemented.
Pum provides the library provides stable, backwards compatible API for applications and for models.
So applications talk to the library and library calls functions from the models.
Everything is configured and nothing has to be no executable has to be or shared library or any binary object has to be attached to do this.
You can install additional models, but at least that is all they have to do is to install the models and configure them.
So for every management group that is a user API for authentication and session management there are two entries.
And for account and password management this just one.
It's kind of important and will I'll mention this later when it's defined when funny thing.
So how all this is configured nowadays?
Well, Pum conversion is service specific and nowadays for each service there is a single configuration file stored usually in it is e.pum.de.
A long time ago the past used to be centralized configure where all services were configured but nowadays like more than decade of things.
It's long in the past so what you get is that.
So for example for login service there is a file literally called lodging in it cpum.de that describes how to.
It configures spam library and describes what models are called in which way.
If for some if the file doesn't exist there is a full back to very to file code author that usually didn't identify success.
Yeah, this way.
We used to configure Pum for many years and at some point we found out that there are a lot of intersections in various configuration files.
So there is an include concept where you can include files one config files from others.
So this is this makes easy to implement system white policies.
So what are actual Pum models they these are things after plaggable authentication models the things after them hoping is called.
They are loaded dynamically according to configuration rest are starting very specific place and there are a lot of them.
There are two specific models standard models that like Pum deny that all the data success and pamper it always permits and they use it as.
Kind of.
Configure blocks.
So let's go through this syntax shortly briefly back in details.
Configuration file each confusion file contains of lines each line has three.
Management fields and one optional.
So first one is type.
It's a the name of the management group.
Therefore them the current control that describes how to treat the return video from the module.
The third is the module name itself.
It could be a path but nobody should be using path to the file nowadays.
And more any modules have optional arguments.
In this simplified example well in all this presentation all examples are real life examples sometimes they are simplified and sometimes they are very much.
So you can see like for some management groups there are more very several lines and for some just a single line.
This by the way this is called stack Pum stack but probably you are aware that it's not a stack.
I mean it's not a lasting first half thing.
And why it's called stack is a bit mysterious.
Nobody could tell me why and I don't remember and I'm involved into Pum development for more than 20 years.
So probably just a pile of things but it's called stack and I will be using this word because it's all in the documentation.
So you can see here like.
This is a way to to silence the air message from the module.
It's in this example you can see this in the dash between the before the before that management group name.
So there are four.
Traditional cultural values one is required that says that the failure of this module will lead to the failure of the whole stack that is the processing of the stack continues but the stack itself is marked as failed.
Now the requisite that differs from required is that the processing of the stack stops at this point and it's a failure.
Why there could be different different controls of that kind.
Sometimes it's not desired to continue processing because like it is unsafe for example it wouldn't make sense to set the password if it doesn't.
But sometimes it's desirable to proceed to avoid information leaks.
For example like if you stop the stack at the point and for example user is not allowed to pass the check for it or whatever.
It would be easy to measure timing and for example easily check whether it uses exist in the system.
There is a sufficient control that says that if the module succeeds then the whole stack succeeds unless it failed before and processing stops at this point.
But if module fails it just the failure ignored.
An optional tricky word that says that the return value from the module doesn't contribute to the result of the stack unless it's the only meaningful module in the stack.
Usually if you see looking into a real file you can see that optional is associated.
It's used with a one group name with a dash because like if module doesn't exist.
For example you can imagine a system as pump system module doesn't exist.
It's a real example from federal configuration.
So they use dash session optional which means if the module doesn't exist then it wouldn't be error in the stack and error wouldn't be printed anyway.
So about 20 years ago I don't remember exactly the include keyword was introduced which is the way to include other lines that are starting a different file.
I don't I I contributed this thing so many years ago to remember when and it has been using used since in various distributions to to use system white policies.
Later sub-stick was introduced it's a way of doing the same but creating a sub-stick which means that failure or not of the stack.
Like for example when it's two minutes prematurely doesn't terminate the whole stack but only the sub-stick where the module was called.
So you can can jump out of this sub-stick and all that kind of things it feels like a sub-stick.
And there is like even more arcane and advanced syntax.
Like you can explicitly specify what will happen for each pump error code.
And there is a keyword default that says that what should happen for all the pump codes that are not explicitly mentioned.
So the actions are similar to to control values to traditional control values so you can ignore.
Let me turn value of mark stack as bad max stack and continue processing max stack as bad and stop processing mark max stack as succeeding if it isn't failing and continue processing and max stack succeeding and stop processing.
If it's not failing and there is a way to jump.
You can specify how many lines in the step should be skipped.
So you can express traditional controls using this advanced syntax and it's sufficiently complicated but still you can jump backwards.
So you can create loops, but you can do branching.
Since you can create loops it's still fairly simple, not too complicated.
So in this example you can see like there is a password jump like for local user.
You jump or they're called to pump TV history module and for in the session stack for it's written that for current service.
They're called to pump units model is skipped for some reason.
It's a funny thing that you see like in the first example ignore equal signal for pump local user.
You have no idea why who wrote this did it this way because pump local user doesn't hit or the code pomegranor.
So this piece is useless but it could be used as an example of how people actually write things.
It's not not a big deal but raises questions.
And the first step thing is it's not very well known concept so I'll touch a bit about this.
This is a real case.
The issue was submitted to us.
I think last year.
And he's an excerpt from the pomegranor version.
Like you see that there is a pump in location and branching on its written video.
And the user asks why the variable isn't set according to the configuration and only one line is printed.
And to understand this we have to recall that for authentication there are two functions.
And what pump library does is during the first indication it fixes the models that are called and the order of these models.
So it freezes the stack.
So for the second time when the second function is called it does the models are called in the sequence.
Then they are called during pomegranate.
And pump in actually does something during this second function that sets credentials.
But well the model is skipped according to the first ignore really.
So for this and probably the user didn't know that pump in does nothing at pomegranate.
And didn't know about the concept of the first stack.
So it looked mystery for them.
But it's pretty simple if you know things.
It's a kind of modern development that started like 20 something years ago and still going on.
As I said earlier pomegranates is a traditional way of authenticating users.
Let's specify the password that against the hash value.
And in the it is a shadow file and access it is a shadow.
You have to be privileged enough.
For example.
Screaser who could be not privileged enough to access this file.
Or if there are is a Linux rules that limit access even for quite privileged processes.
So for pomegranate pomegranates comes with a helper.
And it's traditionally situated.
Later like some distributions, some distributions.
What they did is they installed it is a pump is set up to capabilities that allow access.
But still very risky thing.
So there is an alternative implementation that influences a different way of storing shadow files.
And it's called TCP.
So every user for every user there is a separate directory with the shadow entry.
And so you don't have to be rude.
But still you have to be privileged to access this because there is a group that limit success.
And so it's still somewhat privileged.
For example for people who are doing image based distributions.
Even said get executables are not good.
So the various approach that's available in the latest version that was released last week of Linux pome.
You can build pomegranates with pd access this support.
This way the helper is unprivileged to toll.
And it just communicates with the demon.
In a way like Alexander was mentioning with our models.
This way.
Like many models that do remote education.
You can now have the system without a privileged helper.
Which is nice.
I think.
Okay.
I think you have a few minutes to talk about travel switching.
Then probably the most well-known fear of users is to get it out when they do something with pomegranate configuration.
And like if you use models in not in a correct way or just any very small people who could make the system accessible.
So what could you actually do in this case?
You probably have to use your common sense and first know what you are doing.
And all these traditional recommendations supply like backup before making changes and always test your changes and do your changes incrementally.
And always have an emerging success unless you are ready to deal with it.
Well, unless you are dealing with the disposable system.
And by the way, many distributions have very useful default configuration and tools like in Fedorics of Select.
To simplify configuration of all this pomefiles.
So usually you don't even have to dive into all these details.
But if actually you do have to do something, there is a lot of loss.
For every service you can check the looks and by default pomem is very robust.
And many models they accept debug argument that makes it even more robust.
And what I should have said in the beginning is a lot of documentation and please read the docs there written for you.
Like a lot of month pages is a guide for application developers model developers and system animation developers.
Well, if you have to resolve to real debugging, you can use the burgers.
It would be really odd if I didn't mention stress in this talk, because I'm known as a stress guide.
So if you are in stress, I have few simple recommendations.
Like demons, they usually forks or forks for every user.
So you are going to follow forks.
And you probably want to detach from executables because you don't usually want to debug whatever is being run by the authentication server.
And sometimes to debug all kinds of delays and things related to timings, you can use options, industries to debug timings.
And let's mostly it.
If I have time for questions, you are welcome to ask them.
If not, thank you.
Yes, we have a little bit of time again.
So, I was wondering, you know, with the modules you are going to experiment.
Does parent have a verification or some sort of mechanism to ensure that the malicious replacement of this module?
So the question was whether palm itself has a mechanism to,
whether the right modules are being loaded, whether the right modules are being loaded or not replaced?
By myself, it doesn't do anything or that kind.
Likewise, if you are invoked and executable, it's up to the system.
Essentially, what palm does is load shared objects from the file system.
And they are loaded with their open but using the same mechanism like any shared library is being loaded.
So if the system implements that kind of mechanism for shared libraries, it surely has to implement the same exactly the same mechanism for checking that kind of shared objects.
And the palm itself shouldn't have anything specific because it wouldn't help because other shared objects that are loaded into applications.
They have essentially the same access to the process memory.
So it should be either all or nothing in this case, I think.
Maybe I can have a video.
Yeah, that's for sure.
Some systems they don't just route for that extent and have extra level of validation, but they exist, of course they do.
Peter.
Yeah, we run out of time.
Thank you.