PAM is safe as long as you don't screw with any configuration files, and your file system doesn't corrupt and knock out a possible critical file of PAM.

However, due to the fact in the post install phase, some PAM configuration scripts have to be created, setup, edited, and such, it's hard to say which configuration would overwrite, delete, remove, or possibly foul-up a needed configuration file. As as result, you'd have to have a premade set of configuration files to do everything with the proper permissions, but becasue no two setups and systems are the same, knowing what would be best as a default might not work for user A the same as user B.

Plus, several file systems Slackware uses and supports are know to have issues such as ReiserFS, XFS, and BtrFS respectively.

Here's an example:

/etc/pam.d/other might require as a default:

but another program (such as shadow) may require:

Now you have a conflict of configurations. As a result, you have to either use a default which may not work securely, or you have to use something that's more secure and restrictive, but if the package isn't there to require the restrictive edit, what do you do? Use the default, or use the edit? And if you have a script edit the other config, when you uninstall, does it leave the configuration as-is, change it, or delete it, and what if another program already made other changes? Now what do you do?

To be honest, PAM's configurations are what the problem is. There's no real way to set a viable default that can cover all the system possibilities. What if you install shadow but not OpenSSH? Do you need the setup for OpenSSH? What about xinetd? If xinetd requires it's own special configuration, what if another program uses it and it gets deleted or mishandled?

Yes, PAM adds that would-be nice layer of security and it would be beneficial for Slackware to have it, but PAM requires planning by the end user, lots of planning, and often at times, there is no viable default that can be generally useful to all.

and how do other distributions solve this?
and do they have problem like this?
I mean PAM is shipped since years on all distributions, this is millions of installations.
if it would be such a problem than there would be very many problem reports, do they exist?

I wouldn't know honestly. PAM varies package to package, system to system, user to user. To be honest you could have any number of configurations on any number of systems, so to define a true default is improbable. Even LFS's implementation varies package to package that requires a configuration.

What Fedora does might not be the same as LFS and what LFS uses may not be good for another distribution. The point is, there are too many variables to define a default, even for Slackware.

What would be good for Slackware and what might not? What is good for one package and not another? What is acceptable and what isn't? Should PAM start with less secure or more secure? What packages should be compiled against PAM and what shouldn't?

Ask a million questions, get a million to the power of a million answers. In this compared to PAM, we have no idea of know what would be good for what.

Considering I have been very successful at avoiding the thing for years I am not the best person to answer this concretely, but I will give it a shot at the abstract level. It's quite possible that any specific criticisms I might recall from the last time I tried to configure it are ancient history at this point, without any fundamental change in the architecture I would still consider it unwanted.

First off, system-critical processes, particularly ones directly concerned with security, shouldnt rely on shared modules. There are several serious issues with that, some obvious some subtle, and correct me if I am wrong but I recall PAM was designed to use shared modules anyway, and I dont recall that ever being changed.

Secondly, PAM tries remote logins before local logins. This is a serious architectural mistake, which makes it possible for a fault in remote logins to prevent local logins, effectively bricking your box. Let me repeat that. This makes it possible for a fault in remote login logic to prevent local logins and effectively brick the box. This is insane.

There was a talk about 'polyethelene PAM' that you might look up, it was a long time ago and hopefully some of the specific things that he went into have been fixed, but IIRC the author essentially tried to workaround that basic problem and triggered a cascade of more subtle bugginess as PAM fought back. This was an over-architected system that always thought it knew best and introduced the opportunities for failures both spectacular and subtle as a result.

Authentication, anything critical to the system really, needs to be simple and correct, not complicated and clever. This is the same fundamental objection I have to the systemd/corebuntu stuff. I dont like to tear out simple, correct, robust logic and replace it with a clever rube goldberg device. This is a recipe for lots of trouble, even if it's not always easy to predict exactly what shape that trouble will wind up taking.

PAM? Is she su's sister?
(I've posted this feeble witticism before, and might do again sometime. Sorry.)

4 members found this post helpful.

Except that it doesn't...
You can define remote logins as optional when you configure PAM.

Yeah the order of logins depends on how you have it configured.


You might have something like this, generally:

auth required pam_env.so
auth sufficient pam_unix.so try_first_pass #Try local auth first, if it succeeds, that is sufficient
auth required pam_winbind.so use_first_pass use_authtok require_membership_of=S-1-5-21-11.... #If you didn't auth locally, you must be able to auth to an AD user in a certain security grouop

Each service that uses PAM has its own conf file, other is a fallback conf for unknown services where you could fall back to local unix account auth or simply deny and log, don't see why there would be a conflict. You are right that there should be a carefully thought out set of default confs for any and all services shipping with Slack that would be built against PAM

I said I was taking a risk in saying anything concrete, given that I havent used it in so long. However at least at one time this did not work.

I dug out a link to the paper I mentioned, which explains in detail how it (did not) work at an earlier time. I'm happy to hear that's fixed but I would still suspect the fix may not have been ideal, and the whole system may remain over-architected. Though I'd be happy to be shown otherwise.

http://martin.meltin.net/sites/marti...lythenepam.pdf

The document in PDF format wears no date, but according to this page its date is September 2002. I've no opinion on its content neither on PAM whatsoever, but as we say here, since then de l'eau a coulé sous les ponts de la Seine (computing how many cubic meters is left to the reader as an exercise :-)

That's the point. There are sometimes services that could have variables that may have to be covered by other, as PAM lacks a configuration for that specific service. It's the age old argument of freedom versus security. Too much freedom, and you leave the system wide open, and if you have too much security, something breaks. There has to be a compromise, but because of system variations, there is no real default for a system for everyone, and that compromise is nothing more than vapor in the wind.

All the more reason PAM should not be included. yes, the added security would be nice, but at what cost does it come?

Remember there is no gain without loss, and no pro without a con.

I think this thread has seen enough FUD now and should be buried deep.

8 members found this post helpful.

I doubt crying FUD is going to really help Eric. To be honest with you, I see the benefits Linux-PAM can bring and they are many, but equally there are annoyances Linux-PAM can bring also.

I'm only stating if it is needed, it's deployment needs to be carefully considered before proceeding which is (un)common-sense. Adding a package for the sake of adding a package is reckless. Call that FUD all you or anyone wants. All I'm saying is plan thoroughly, be careful, and consider all options to brings benefit with the least instances of problems.

If that's FUD, then common sense is truly dead.

Wise advices. Followed since 21 years by Pat. Does he need a reminder?

5 members found this post helpful.

I live in the mountain, near to Parque Natural del Monseny in
Barcelona. Unfortunately in a urbanization with a noisy highway below
and a lot of neighbours using machines every day (chainsaw, lawn mower,
cultivation equipment, etc). I have a organic vegetable patch, I needed
just a shovel to do it. I go to town with a shopping bag, like 40 years
ago, and fight with the sellers every day to avoid consuming more
plastic than food. I've never had a car. I wash my clothes by hand and
I turn off my refrigerator on winter. I made of it my way of life
because a reason, without health nothing is important. I take care of
the environment.

Some months ago my neighbour reported me to the police for not to mow
the lawn. He won, I was forced to do it (no, his name isn't Lennart),
even if it's a none sense, it's right just because it's what everybody
does. What they call economical "crisis" delayed the urbanization
process that means to kill each every tree on one of the last nice green
places in Catalunya, they think nature is grime (and fire danger), and
they know I'm the only one against paving. They hate me. Yes, I am
"the troll" in my neighborhood too :-).

I don't need to explain you what photosynthesis is and how besides it
produces oxygen it reduces carbon (temperature insulation) in *our*
atmosphere. You know the influence of climate in your life, in your
health. You understand all that, you're not a retired catalonian
peasant like my neighbour, you're a cult young parisian. To not breathe
oxygen is not a personal preference. An unhealthy life is not a
personal preference, it's not about taste. You realize of that when you
get old.

In the same way "normal" people in my neighbourhood call me "hippie"
(I'm not a hippie, I have a big led TV and a intel i5 at home) to
discredit my point, you use analogies in a pejorative way. To build
cathedrals out of matchsticks or cramming ocean steamboats into bottles
are just hobbies. I wouldn't directly compare that hobbies with:

I am a very bottom-up thinker. If you give me the right kind of Tinker
Toys, I can imagine the building. I can sit there and see primitives
and recognize their power to build structures a half mile high, if only
I had just one more to make it functionally complete. I can see those
kinds of things. -- Ken Thompson

Unix was small, and you could go through it line by line and
understand exactly how it worked. That was the origin of the so-called
Unix culture. -- Ken Thompson

Anyway, let's pretend it's about taste. Imagine you go to a sports
center with 30 football and only one tennis field. You want to play
tennis but there are people playing football in the tennis field too.
If you complain they will call you troll. That's what happens at all
levels in life. If you ask some of them why football he will answer you
"it's my personal preference".



By the way, I spent 20 days in Paris time ago and knew nice, wonderful
people. I talked English with most of them without problem. I bet on
your pupils are perfectly able to understand an English software
interface and they "don't want" because of some pseudo cultural identity
reason.


David Banner
Physician/Scientist


--
Edited with Vim (tw=72) using pentadactyl firefox plugin

2 members found this post helpful.