gmane.linux.pam

Re: managing the /etc/pam.d files

Shawn Wells — 2013-05-23T22:23:00

:s/source for Spacewalk/source for Satellite/r

Some docs < at > 
https://access.redhat.com/site/documentation/en-US/Red_Hat_Network_Satellite/5.5/html-single/Reference_Guide/index.html#sect-Reference_Guide-Configuration

Re: managing the /etc/pam.d files

Shawn Wells — 2013-05-23T22:17:29

Puppet works wonderfully.

And if you're running RHEL, consider checking out RHN Satellite (which 
provides centralized config management). CentOS systems could use 
Spacewalk (upstream source for Spacewalk).

managing the /etc/pam.d files

Joseph Lutz — 2013-05-23T16:49:39

Is anyone aware of some opensource software that will manage a systems
/etc/pam.d configuration. I am looking for some software that I can tie
into our Web Management system that will take care of writing changes to
the pam.d files. Currently I am using come complected python programs that
work fine for the particular setup that we are running. But
I foresee changes needed in our setup. If I am going to rewrite part of the
pam file management code I want to check if there is something already
available to do at least part of the work.


Joseph Lutz
Software Developer
NovaTech, LLC
13555 W. 107th Street
Lenexa, KS 66215
_______________________________________________
Pam-list mailing list
Pam-list< at >redhat.com
https://www.redhat.com/mailman/listinfo/pam-list

Differences in Conversation function between distributions?

Mike Wham — 2013-04-30T18:09:36

Hello all,

I'm trying to determine why there seems to be a discrepancy between PAM on
Ubuntu and PAM on CentOS and Archlinux.

For example, a script that works nicely on Ubuntu ("pam_python") throws
errors on the other distributions, with errors like: "pam_conv() takes
exactly 3 arguments (2 given)."  Why would this be?  Are there different
versions of the conversation function present in each distribution? For the
record, I think the latest Ubuntu uses PAM 1.1.3, whereas the others use
1.1.6.

Best,
Mike
_______________________________________________
Pam-list mailing list
Pam-list< at >redhat.com
https://www.redhat.com/mailman/listinfo/pam-list

Question about 'session' in pam w/rt pam_env.so

L.A.Walsh — 2013-04-22T19:55:41


I was wondering how one is supposed to preserve env variables set when

one initially logs into a system (like the same time loginuuid is set). 
Specifically,
ENV vars 'DISPLAY' and 'REMOTEHOST'.  I use the 2nd to generate the first and
want it to last for the entire time I am logged in.

I have been setting it in pam_env, using a similar example.

Now I find that some see pam_env as a means to set the environment
*per session* -- meaning they call it again during the common-session phase,
in addition to the 'auth' phase.  This has the tendency to overwrite
those variables. 

I'm told that there's no way to prevent this as if the user
clears their env (e.g. 'env -i), and that means it has to be called at the
beginning of each session so it can reset env vars (this despite the fact,
that I know of no one using such functionality, whereas I had been using
it for 'auth' only on initial system entry.

I can see the need for a session-based pam_env to generate a new
user environment (though right now, in my distro, the ENV is set
via shell scripts on initial login).

however, if I leave my distro's defaults in place, my display and remote
host are overwriten when I do a "sudo su" -- to get a new shell as root.

Is there a way to protect those vars, as right now, even though I
specify the -m flag to 'su', it seems not to preserve my env when I
invoke it via sudo. 

So how I can limit pam_env's resetting to save and carry forward
item's like remotehost and DISPLAY -- OR -- should pam_env only
be called during 'auth' and env-init should be left to shell scripting
(or putenv)...

I'm aware of the comment that says the module should be an AUTH
module, but I've been told that was only the initial design and that
the manpage and other docs allow for using it to initialize sessions.

Ideas or suggestions on how to do this would be great.
Thanks!
LW

Re: are there "session IDs"?

Pavel Kankovsky — 2013-03-24T20:14:18


You cannot associate an SSHv2 session with a terminal because SSHv2 allows
any number of tty channels within a single session (none, one, more).  
In fact it provides two separate procedures: you log in first and you
create tty channels running programs (e.g. a shell) later when the session
is established.


I am afraid there is no such identifier.

You can generate your own unique id when the session is opened, store it
with pam_set_data() and fetch it with pam_get_data() when the session is
closed. Unfortunately, PAM specs seem to be quite lenient do not require
the application to call pam_sm_open_session() and pam_sm_close_session() 
with the same pam_handle_t.

Re: changing password prompt

Ali Corbin — 2013-03-23T04:43:37

On Fri, Mar 22, 2013 at 11:16 AM, Smith, Gina C. (MSFC-IS40)[NICS]
<gina.smith< at >nasa.gov> wrote:

When I had to do this I wrote a small pam module that did nothing but
set PAM_USER_PROMPT and stuck it in the stack in front of pam_unix.

Ali

Re: changing password prompt

David Mitton — 2013-03-23T03:36:10

I think if you dig a bit, you'll find that PAM does not do the prompting.
Typically it's done by the authenticating app.
Which does make it difficult to change the prompts to match the  
credentials you are really asking for.

Dave.


Quoting Rachel Polanskis <grove< at >zeta.org.au>:

Re: changing password prompt

Rachel Polanskis — 2013-03-22T23:57:15

If you have the source code to something, anything is possible......

--
rachel polanskis 
<r.polanskis< at >uws.edu.au> 
<grove< at >zeta.org.au>

On 23/03/2013, at 5:16, "Smith, Gina C. (MSFC-IS40)[NICS]" <gina.smith< at >nasa.gov> wrote:

_______________________________________________
Pam-list mailing list
Pam-list< at >redhat.com
https://www.redhat.com/mailman/listinfo/pam-list

changing password prompt

Smith, Gina C. (MSFC-IS40)[NICS] — 2013-03-22T18:16:14

When sshing into a box that is set up to authenticate via radius using pam.  Is there a way to change the prompt from 'password' to 'passcode'??

Thanks
_______________________________________________
Pam-list mailing list
Pam-list< at >redhat.com
https://www.redhat.com/mailman/listinfo/pam-list

are there "session IDs"?

Seven Reeds — 2013-03-19T21:58:29

Hi,

I am running Ubuntu.

I am writing an executable that pam_exec will call in "session" mode.
It will respond to session open/close events.  It is almost completely
working.  This morning I was testing it using "su" and it was doing
what i expected.  I then started ssh-ing to the machine.  That's when
things became puzzling.

if I "su" while on the machine the PAM_TTY environment variable is
indeed a TTY string and is unique to the "session".  However, if I
treat "ssh" like "su" and try to ssh to a different user on the same
machine, ex:

        $ ssh otherUser< at >this.machine.com

then the PAM_TTY variable just shows "ssh".  If I were logged in
multiple times then all would appear to be on the same "line", so to
speak.

This does make sense I suppose.  The "su" continues to use the tty of
the caller.  The "ssh" will eventually have a new tty.  I am calling
my PAM_EXEC's program very late in the session stack so I assumed that
a tty would be available.

Since the tty is not available, is there a unique session identifier
that I can use?  I have not seen mention of one.

Seven

Re: pam modules and setuid actions

Seven Reeds — 2013-03-13T17:00:42

Thanks Thomas.  I had not seen it stated anywhere about the effective
0 uid.  That is not the behaviour I am seeing and as you say, broken
calling apps may muck this up.

I'm going to write my own setuid executable and use pam_exec.  thanks all



On Wed, Mar 13, 2013 at 11:39 AM, Tomas Mraz <tmraz< at >redhat.com> wrote:

Re: pam modules and setuid actions

Tomas Mraz — 2013-03-13T16:39:33

On Wed, 2013-03-13 at 11:02 -0500, Seven Reeds wrote: 

PAM session modules (that is the modules configured in the session stack
and called through the pam_sm_open_session() and pam_sm_close_session())
expect to be called with effective uid == 0. So there should be no need
to add any setuid helper for this functionality. Of course there might
be non-compliant applications that call the session modules with regular
user id but other modules will be broken for them as well.

Re: pam modules and setuid actions

Seven Reeds — 2013-03-13T16:02:25

Sorry, I was not clear.  I'll try again.

I have written a PAM shared object (.so) module.  It should log PAM
session related info to a remote database at session start and stop.
In the rare times when there are network issues I would like the
module to log to a local cache file.  When the network is
reestablished I want to send all the cached records to the remote DB.

I want the cache file to exist in a protected part of the file system.
 It should be owned by root or some other user.  It should not be
generally accessible by the "public".

Since this is a shared object module I do not seem to control the
"setuid" nature of the instigating program like "su", or "ssh".  I am
doing my development on a somewhat old Ubuntu machine.  As it happens
"su" is installed as setuid-root and ssh is not setuid at all.  So I
was wondering if PAM had some magic to handle this situation?

Right now I think that my best bet is to write my own setuid
executable and use "pam_exec".

all the best

Re: pam modules and setuid actions

Dylan Martin — 2013-03-12T19:21:47

You have a cache file that you can open as root, but not using su or
sudo or your suid binary?  Is that right?  That's weird.  You're not
operating in a filesystem that's mounted nosuid, by any chance?

The only problem I can see with your approach is that suid is kindof
all-or-nothing.  If your binary does anything before it operates on
the cache file, it will also be root until you can well-and-truly drop
root privileges after dealing with the cache file.

An alternative might be to make your binary suid some-other-user.  So,
say the cache file belongs to a user named cacheface and only
cacheface can read or write to that file.  Your cache-editing binary
could be suid cacheface.

You can make a binary who's only job is interacting with the cache,
and have your main program call that suid binary.  (that's how a lot
of shadow password stuff works)

You could make a server that opens the cache (or keeps in in memory)
and you log to it instead of to the remote host.

You could use syslog with remote logging. (probably totally misses the point)

You could stop eating so much fatty food, call your mother from time
to time and share that recipe for cold fusion you've been hiding...
;-)

Yar!
-Dylan

On Tue, Mar 12, 2013 at 11:14 AM, Seven Reeds <seven.reeds< at >gmail.com> wrote:

pam modules and setuid actions

Seven Reeds — 2013-03-12T18:14:34

Hi,

I am very close to finishing a pam module that will log specific user
session activities to a database.  There could be situations though in
which the primary, remote DB is unavailable so I want to create a
local "cache" of loggable events.  Once remote DB access is regained I
will upload the cache records and be very happy.  There is an issue
though.

I want the cache to live in protected space.  I would like to open the
cache as "root" or some other dedicated user.  I do not want the
general public to inspect or edit the cache.  I have just tried
wrapping the cache "open" in setuid calls but that has not worked.  I
am using "su" as my testing tool but even though the "su" executable
is setuid by default the open section fails.

Is there a general PAM related solution to this?

thanks
Seven

Using PAM in setuid processes

Simon McVittie — 2013-01-24T19:22:34

Hi,
I've recently been looking at the security properties of various setuid
executables, many of which use PAM for authentication.

What is PAM's policy on the extent to which modules may trust the
process' execution environment, particularly environment variables?

I can see three options for a consistent policy:

1) PAM is considered safe to use in a setuid process, even if the
environment has not been "cleaned". Modules must not use libraries
or execute helper programs that can be adversely affected by
environment variables.

2) PAM is only considered safe to use in a setuid process if the
environment has been "cleaned" against a whitelist. Modules may use
any library, or execute any helper program; privileged processes
that are run with a potentially-attacker-controlled environment
must "clean" it before using PAM. If the process intends to use the
original environment later, it can save a copy before cleaning it,
and pass that copy to execle or similar.

3) There is some mechanism that can/should be used in modules to decide
whether the process in which they are hosted is privileged or not.
If it is, they must ensure that they ignore environment variables;
if it is not, they may obey environment variables.

Which of these policies do the PAM maintainers consider it to have?

For some examples of setuid executables which behave defensively and
clear the environment (i.e. behaving as if the policy is (2), but also
OK for either of the others), see polkit's pkexec[1] and
polkit-agent-helper-1[2].

[1] http://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c
(saves the old environment first, and may pass a filtered subset
to the executed program)
[2]
http://cgit.freedesktop.org/polkit/tree/src/polkitagent/polkitagenthelper-pam.c#n76
(clears the environment altogether)

For examples of setuid executables which do not clear the environment
(i.e. assuming that the policy is (1)), see most su implementations.

Here are some examples of things modules in these processes can't be
allowed to do without special precautions if policy (1) is in effect:

* trust executables in $PATH
* trust $IFS not to be something that will confuse a shell script
* connect to $DBUS_SESSION_BUS_ADDRESS or $DBUS_SYSTEM_BUS_ADDRESS
(either of which can contain a command to start a "tunnel")
* load code from $PERL5LIB, $PYTHONPATH, $PYTHONHOME etc.
* trust UTF-8 input in conjunction with PERLIO=:utf8
* trust that $TZDIR is non-malicious
* connect to $DISPLAY? (if the X11 protocol is such that connecting to a
socket specified by an attacker can cause bad things to happen)
* (etc.)
* execute an external command that does any of those

sudo(1) has a long list of variables that are considered unsafe.

If PAM doesn't have a policy for this, I would personally advocate
policy (2), as recommended by
<http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/environment-variables.html>.
I do notice that this would break use of pam_xauth in setuid
executables, although it isn't clear to me whether that would make sense
anyway.

For the DBUS_* variables this was reported as CVE-2012-3524, and
mitigated in libdbus and GDBus by distrusting environment variables if
getuid() != geteuid() (so, a partial implementation of policy (3), but
perhaps not with the same mechanism to detect privilege that you'd choose).

I'm mainly interested in environment variables and setuid at the moment,
but similar considerations apply to other bits of process environment
that are inherited from a parent that can be less privileged (most
notably, current working directory), and to mechanisms for privilege
escalation other than setuid (setgid, Linux filesystem capabilities, etc.).

Opinions?

Regards,
Simon

Re: Can I set the user to authenticate as?

Tomas Mraz — 2013-01-08T18:45:53

On Fri, 2013-01-04 at 16:13 -0800, Dylan Martin wrote: 

You can put the mapping module after the pam_imap.so to set the PAM_USER
back to the original value which you can save with pam_set_data().

Re: Can I set the user to authenticate as?

Dylan Martin — 2013-01-08T18:25:06

I'm sorry, I must have failed to explain myself well.  (Sadly a normal
occurance).

getpwnam should return the name the user typed into the login prompt.
The other name is only used by PAM when interacting with the
authentication source, in this case, an IMAP server.

Example:
Web account = geology
IMAP account = jdoe

The user types in 'geology' at the login prompt and they type in the
password to their imap account.  My weird module looks up geology in a
table and finds 'jdoe' or whatever.  My module somehow tells the next
module , pam_imap to use 'jdoe' instead of 'geology'.  Then, somehow,
PAM uses 'geology' for session and so forth.

On Tue, Jan 8, 2013 at 9:16 AM, Martin <inkubus< at >interalpha.co.uk> wrote:

Re: Can I set the user to authenticate as?

Martin — 2013-01-08T17:16:07

You may also have to create an NSS module that performs the same
translation / canonicalisation so that user information functions
(getpwnam et al.) work as expected.

Cheers,
 - Martin

Re: Can I set the user to authenticate as?

Wolfgang Draxinger — 2013-01-08T01:12:22

On Fri, 4 Jan 2013 16:13:27 -0800
Dylan Martin <dmartin< at >seattlecentral.edu> wrote:


Theoretically this is possible. However some services do break under
these conditions if the username changes. For example OpenSSH has a
problem with this. The main exception is, if characters are turned
upper- or lowercase.

Some time ago I did write a PAM module that indeed alters the username.
You can find the source code here:
https://github.com/datenwolf/pam_propperpwnam


|pam_propperpwnam
|
|A PAM module that uses the entered login name as key to
|query the password database configured through nsswitch.conf
|and replaces the login name with what has been returned.
|
|On the typical system this module performs an identity transform.
|The main usage scenario are systems in networks where a user name
|is used in several distinct authentication systems, some of them
|being case sensitive and others not. For example the mail system
|may do case insensitive username lookups, while the workstations
|are case sensitive. In such environments users are often puzzeled
|about a username working in one situation does not work in another.

There's a pam_python module, that allows you to write PAM modules with
Python. This is great for experimentation, I suggest you experiment
with this.

But keep in mind that some things will break if you alter the login
name; technically those things are broken and should be fixed. Good
luck with filing bugs.


Cheers,

Wolfgang