LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 07-22-2014, 11:02 PM   #46
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 4,245
Blog Entries: 15

Rep: Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320

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:

Code:
auth            required        pam_unix.so     nullok
account         required        pam_unix.so
session         required        pam_unix.so
password        required        pam_unix.so     nullok
but another program (such as shadow) may require:

Code:
auth        required        pam_warn.so
auth        required        pam_deny.so
account     required        pam_warn.so
account     required        pam_deny.so
password    required        pam_warn.so
password    required        pam_deny.so
session     required        pam_warn.so
session     required        pam_deny.so
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.

Last edited by ReaperX7; 07-22-2014 at 11:08 PM.
 
Old 07-23-2014, 02:09 AM   #47
a4z
Member
 
Registered: Feb 2009
Posts: 724

Rep: Reputation: 263Reputation: 263Reputation: 263
Quote:
Originally Posted by ReaperX7 View Post
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?
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?
 
Old 07-23-2014, 04:44 AM   #48
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 4,245
Blog Entries: 15

Rep: Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320
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.
 
Old 07-23-2014, 05:03 AM   #49
Arkerless
Member
 
Registered: Mar 2006
Distribution: Give me Slack or give me death.
Posts: 81

Rep: Reputation: 60
Quote:
Originally Posted by abesirovic1 View Post
For educational purposes, why is PAM bad (I'm not trolling, I'm just curious)?
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.

Last edited by Arkerless; 07-23-2014 at 05:05 AM.
 
Old 07-23-2014, 05:36 AM   #50
brianL
LQ 5k Club
 
Registered: Jan 2006
Location: Oldham, Lancs, England
Distribution: Slackware & Slackware64 14.1
Posts: 7,283
Blog Entries: 55

Rep: Reputation: Disabled
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.
Old 07-23-2014, 05:56 AM   #51
Slax-Dude
Member
 
Registered: Mar 2006
Location: Valadares, Portugal
Distribution: Slackware
Posts: 290

Rep: Reputation: 79
Quote:
Originally Posted by Arkerless View Post
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.
Except that it doesn't...
You can define remote logins as optional when you configure PAM.
 
Old 07-23-2014, 09:51 AM   #52
NeoMetal
Member
 
Registered: Aug 2004
Location: MD
Distribution: Slackware
Posts: 112

Rep: Reputation: 23
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
 
Old 07-23-2014, 09:59 AM   #53
NeoMetal
Member
 
Registered: Aug 2004
Location: MD
Distribution: Slackware
Posts: 112

Rep: Reputation: 23
Quote:
Originally Posted by ReaperX7 View Post

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

Code:
auth            required        pam_unix.so     nullok
account         required        pam_unix.so
session         required        pam_unix.so
password        required        pam_unix.so     nullok
but another program (such as shadow) may require:

Code:
auth        required        pam_warn.so
auth        required        pam_deny.so
account     required        pam_warn.so
account     required        pam_deny.so
password    required        pam_warn.so
password    required        pam_deny.so
session     required        pam_warn.so
session     required        pam_deny.so
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.
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
 
Old 07-23-2014, 02:16 PM   #54
Arkerless
Member
 
Registered: Mar 2006
Distribution: Give me Slack or give me death.
Posts: 81

Rep: Reputation: 60
Quote:
Originally Posted by Slax-Dude View Post
Except that it doesn't...
You can define remote logins as optional when you configure PAM.

Quote:
Originally Posted by NeoMetal View Post
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
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
 
Old 07-23-2014, 02:47 PM   #55
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad W520
Posts: 5,003

Rep: Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358
Quote:
Originally Posted by Arkerless View Post
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 :-)

Last edited by Didier Spaier; 07-23-2014 at 02:51 PM.
 
Old 07-23-2014, 09:45 PM   #56
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 4,245
Blog Entries: 15

Rep: Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320
Quote:
Originally Posted by NeoMetal View Post
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
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.
 
Old 07-24-2014, 12:01 AM   #57
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,492

Rep: Reputation: Disabled
I think this thread has seen enough FUD now and should be buried deep.
 
8 members found this post helpful.
Old 07-24-2014, 04:22 AM   #58
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 4,245
Blog Entries: 15

Rep: Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320Reputation: 1320
Quote:
Originally Posted by Alien Bob View Post
I think this thread has seen enough FUD now and should be buried deep.
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.
 
Old 07-24-2014, 05:04 AM   #59
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad W520
Posts: 5,003

Rep: Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358Reputation: 1358
Quote:
Originally Posted by ReaperX7 View Post
[...] if it is needed, it's deployment needs to be carefully considered before proceeding [...]. Adding a package for the sake of adding a package is reckless. [...] plan thoroughly, be careful, and consider all options to brings benefit with the least instances of problems [...].
Wise advices. Followed since 21 years by Pat. Does he need a reminder?

Last edited by Didier Spaier; 07-24-2014 at 05:07 AM.
 
5 members found this post helpful.
Old 07-24-2014, 09:15 AM   #60
eloi
Member
 
Registered: Nov 2010
Posts: 227

Rep: Reputation: 61
More off-topic on-topic

Quote:
Originally Posted by kikinovak View Post
A few years back, I went to see a friend of mine, a writer who lives in a very remote village up in the mountains in Austria. He asked me if I wanted to eat fish for dinner, and when I accepted enthusiastically, he grabbed his fishing gear, and we went to a nearby river. He's an experienced fisher, and after an hour or so, we had four big trouts in the bucket. As soon as we arrived home, he started cooking the fish, using potatoes and herbs from his garden, and the meal was delicious.

I like a similar approach for other things in life, operating systems for example. But I think that if my friend had asked me to raise some trouts first, I would politely decline and suggest we simply go to a restaurant instead. While I am a very patient person and like to experiment and fiddle a lot, I'm not the guy who builds cathedrals out of matchsticks or who crams ocean steamboats into bottles for relaxing.

Cheers,

Niki
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.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
PAM and Slackware 10.2 darkarcon2015 Slackware 15 10-20-2007 03:32 PM
PAM Available For Slackware 10.0 eric.r.turner Slackware 14 09-22-2006 01:08 PM
PAM for my Slackware rmg Linux - Newbie 3 04-06-2006 02:10 PM
does slackware 10 support PAM? joroxx Slackware - Installation 2 11-16-2004 01:06 AM
pam mount in slackware 10 qwijibow Linux - Software 1 08-06-2004 09:37 AM


All times are GMT -5. The time now is 04:45 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration