The Good PAM Flashcards
What are the four things that make up a PAM statement
TYPE
CONTROL
MODULE
ARGUMENTS
IN ORDER:
auth required pam_unix.so no_warn try_first_pall nullok
Describe Type
Describe what the module will be dictating
Auth - authorization
Account - specifies account settings. User can log in every other day of the week
Session - How session is taken up and torn down. Created this directory, then take it down.
Password - For updating auth creds.
Describe Controls
How PAM reacts to success or failure.
Required - Must return success for access. If fail it will go through remaining modules. All encompassing no.
Requisite - must succeed for access, can fail to future modules. Failure is a stopping point though. Only use when you have to, bad for security.
optional - If no other control has a say this will normally give a success. Good for additional functions like giving you a time out between bad logins.
sufficient - Success is enough to provide access if a required isn’t failed. No further modules are processed for success, for a failure though it no biggie, it’s an optional failure and isn’t concrete. If you end with this always make a pam_denied
auth required pam_denied.so
binding - not used. Stops on success, failure moves on
include - pull one policy into another
binding
include
What are arguments/flags
Additional options for your particular module
debug - log debugging via syslog
no_warn - gives you back no reason for failure
use_first_pass - Doesn’t request your password over per module, just use the original one.
try_first_pass - Use previous pass but if that doesn’t work use a new one.
expose_account - prints to the stdout the issue of what’s wrong.
Name some common modules
pam_unix.so - Interactions with baseline password files /etc/group passwd and shadow
pam_wheel.so - Allow access if in wheel group or you can specify group:
auth required pam_wheel.so group=animals deny
pam_permit.so
pam_deny.so
pam_exec.so - run a command
Deny a group from accessing ssh
vi /etc/pam.d/sshd
auth required pam_wheel.so group=animals deny
PAM return codes and functions
Return Code - Found in module documentation, every module will give exactly 1
Function - Dialog of what pam is doing, you won’t see these.
What are extended controls?
They can be used to replace your standard controls. They determine how the module handles rejection.
auth [user_unknown=ignore success=ok ignore=ignore \
default=bad] pam_securetty.so
These are just pam responses minus the “PAM_” part. For instance, PAM_SUCCESS is just success=ok
What are the extended control actions?
bad - Will process rest of modules but this is a failure
die - request has failed, stop processing
ok - Success if everything before and after is ok
done - Success, stop processing, failure if previous failure though
ignore - response doesn’t alter policy response. Earlier bad or ok still stands
reset - throw away previous bad or ok
number like 1, 3, etc. - Skip that many following modules.
What would the below policy do:
auth required pam_breathalizer.so
auth requisite pam_ddr.so
auth required pam_genescan.so uth required
Need to pass breathalizer or you get an all encompassing failure, but it will continue.
ddr needs to be success, this will stop processing policy if failed.
genscan is required if ddr is succeeded, will continue processing though.
Make a control like required, requisite, etc using only Extended Controls
Required:
auth [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
Requisite:
auth [success=ok new_authtok_reqd=ok ignore=ignore default=die]
Sufficient:
auth [success=done new_authtok_reqd=done default=ignore
Optional:
auth [success=ok new_authtok_reqd=ok default=ignore]
PAM_NEW_AUTHTOK_REQD = password should be changed
Show the reason why you were booted from a ssh login
vi /etc/pam.d/sshd
auth optional pam_exec.so expose_account
substack control vs include control
substack - a failure in a substack doesn’t cause a failure in your main policy, it will just fail that substack. This can return a success or failure but will continue on to your policy.
This makes the secondary substack policy act like a required statement as it keeps going but holds fast to the failure.
Create a policy statement that says if a user doesn’t match root to allow them access
auth required pam_succeed_if.so user != root quiet_success
REMEMBER, ALTHOUGH YOU CAN USE : IN “INGROUP” STATMENTS, “:” DOESN’T WORK FOR JUST “USER”
Create a policy statement that says to deny access if a user is not mwl jkh or des
What if you want them to allow if in a group.
auth required pam_succeed_if.so user notin mwl:jkh:des
ingroup
