- Package:
- libpam-script
- Source:
- libpam-script
- Description:
- PAM module which allows executing a script
- Submitter:
- "Andreas B. Mundt"
- Date:
- 2014-10-19 13:21:08 UTC
- Severity:
- wishlist
Hi,
I am using libpam-script to execute a script in debian-lan when a user
logs in. Now, with the move to wheezy, I can log in as root with no
password given at the prompt.
The reason is, that the script pam_script_auth exits with 0, which is
'sufficient' for login with the patch from #670182. Before I was
using 'auth optional pam_script.so' in /etc/pam.d/common-auth as
documented in /usr/share/doc/libpam-script/examples/README.examples :
For Ubuntu/Debian:
cat >>/etc/pam.d/common-account <<!
account optional pam_script.so
!
cat >>/etc/pam.d/common-auth <<!
auth optional pam_script.so
!
cat >>/etc/pam.d/common-password <<!
password optional pam_script.so
!
cat >>/etc/pam.d/common-session <<!
session optional pam_script.so
!
From reading the docs, I do not expect that the successfull execution
of my script is sufficient to log in (as root without password) by
default. Cf. /usr/share/doc/libpam-script/README :
Description:
PAM-script allows you to execute scripts during authorization,
passwd changes, or session opening or closing.
So if you need extra work done after login you can use this
pam module to execute a session script
So I would like to strongly suggest to modify the patch from #670182 and use either
'optional' or 'required' in the pam stack and not 'sufficient' by default.
Best regards,
Andi
Hi,
I think the patch below should address the issue. I am not completely
sure about the "*-Type: Additional", but from [1] and [2] and the
links there I think it should be as below.
This modification follows the principle of 'least surprise': Neither
you are loged in without password as before with 'sufficient' and an
arbitrary script exiting 0, nor you are unable to log in which
might happen with 'required' and a script exiting non-zero. So I
guess this is a good default.
CC Gaudenz to allow for his input/comments too.
Best regards,
Andi
[1] https://wiki.ubuntu.com/PAMConfigFrameworkSpec
[2] https://bugs.launchpad.net/ubuntu/+source/libpam-ldap/+bug/962560
--- libpam-script-1.1.6.orig/debian/pam-configs/pam_script 2014-08-28 21:50:17.307750928 +0200
+++ libpam-script-1.1.6/debian/pam-configs/pam_script 2014-08-28 22:35:31.706170198 +0200
@@ -1,15 +1,15 @@
-Name: Support for authentication by external scripts
+Name: Support for executing scripts
Default: yes
Priority: 257
-Auth-Type: Primary
+Auth-Type: Additional
Auth:
- sufficient pam_script.so
-Account-Type: Primary
+ optional pam_script.so
+Account-Type: Additional
Account:
- sufficient pam_script.so
-Password-Type: Primary
+ optional pam_script.so
+Password-Type: Additional
Password:
- sufficient pam_script.so
+ optional pam_script.so
Session-Type: Additional
Session:
optional pam_script.so
Hi "Andreas B. Mundt" <andi@debian.org> writes: Thanks for CCing me. I was not aware of your bug report before. IMO the proposed patch is wrong. If your pam script is not intended to authenticate users, then don't use it in the authentication phase. If the script is used to mount network shares or similar things, put it into the session phase. Having auth scripts be optional by default, just leads to a situation were everyone that want's to use a script for authentication has to modify the pam configuration as this default most certainly won't be right for his case. If you want to change the default, then better change it to required, but this has the disatvantage you discribed of fatal failures. Regards, Gaudenz
Hi, Thanks will investigate patch and suggested solutions. Regards, Martijn van brummelen
Hi,
Well, a script in the authentication phase can either be sufficient
for authentication, or it can further limit authentication. If you
look at the examples in '/usr/share/doc/libpam-script/examples/',
the README.examples explains how to use a script 'tally' [1] to limit
the number of login attempts, or imagine the restriction to time slots
where login is allowed. For all these cases using 'sufficient' is
fatal, as any other authentication method is bypassed.
Sure, depending on what you want to do (further restrict or allow) you
have to modify that configuration. The question is: "What is the
most common configuration?" and "Which configuration can/cannot cause
harm by default?".
I think optional is fine. It does not undermine the authentication
already in place by the examples returning zero by default. It does
not lock out everybody if the script returns non-zero. If either
'sufficient' or 'required' are needed, the system is modified anyway,
and the sysadmin implementing this will test if things work as
expected. There will be no surprises.
However, I agree that 'required' is still much better from a security
perspective than 'sufficient'.
Best regards,
Andi
[1] <URL:http://sources.debian.net/src/libpam-script/1.1.6-1/etc/tally/>,
it looks like it's not shipped in the binary package.
Hi! Jut letting you know that because of this bug, libpam-script has been marked for deletion from testing. This means it won't reach stable!!! Hope you can fix it soon (or mark as wontfix if it's expected behaviour). Regards Sebastià
The correct url to the mailinglist is [0] Regards, Martijn van Brummelen [0]https://lists.debian.org/debian-devel/2014/10/msg00137.html
Im not sure if the suggested patch is ok or not, or provide a better patch? I asked on debian devel mailinglist[0]]/irc but did not get much response. It would be a pitty if Jessie would be released without it. Can someone advice me on this? Regards, Martijn van Brummelen [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759559
Hi Martijn Martijn van Brummelen <martijn@brumit.nl> writes: Surely not having the package in testing and thus jessie is the worst option. So there needs to be a fix for this bug very soon. Here are my thoughts about it: 1. IMO the severity and tags of this bug are overrated. One possible solution is to just downgrade this to wishlist and remove the security tag. I'm not at all convinced that this is a security problem in your package. One thing you have to make sure in this case is that you don't overwrite any configuration already in place. So if it's set to optional in the authentication phase before the upgrade it should stay at this setting. Everything else is a Debian Policy violation. Not overwriting the existing configuration solves the security problem. There is no security problem on new installs IMO. If someone installs a script that allows unconditional authentication and does not check the pam-script configuration, then this is a configuration error outside of your package. 2. Basically this is an issue about the right default policy for the authentication phase of libpam-scripts. This is IMO something you as the maintainer can decide. Every value is right in some cases and wrong in others. There is no single value that will suit everyone. I proposed sufficient as the default value, but I can live with every setting and agree that there are good reasons to change the setting. Probably optional is indeed the most conservative setting. But also the one that means that the setting must be changed for many use cases. Gaudenz
Hi Martijn Martijn van Brummelen <martijn@brumit.nl> writes: Surely not having the package in testing and thus jessie is the worst option. So there needs to be a fix for this bug very soon. Here are my thoughts about it: 1. IMO the severity and tags of this bug are overrated. One possible solution is to just downgrade this to wishlist and remove the security tag. I'm not at all convinced that this is a security problem in your package. One thing you have to make sure in this case is that you don't overwrite any configuration already in place. So if it's set to optional in the authentication phase before the upgrade it should stay at this setting. Everything else is a Debian Policy violation. Not overwriting the existing configuration solves the security problem. There is no security problem on new installs IMO. If someone installs a script that allows unconditional authentication and does not check the pam-script configuration, then this is a configuration error outside of your package. 2. Basically this is an issue about the right default policy for the authentication phase of libpam-scripts. This is IMO something you as the maintainer can decide. Every value is right in some cases and wrong in others. There is no single value that will suit everyone. I proposed sufficient as the default value, but I can live with every setting and agree that there are good reasons to change the setting. Probably optional is indeed the most conservative setting. But also the one that means that the setting must be changed for many use cases. Gaudenz
Hi Martijn, hi Gaudenz!
I almost agree with the above. I have no idea if the package is more
often used with Gaudenz' settings ('sufficient') or with the
'optional' I suggested. (Before this discussion, I never thought
about the way Gaudenz used the package, but that might be due to
my limited view.)
I can live with both settings too, of course. Perhaps it would be
good to mention Gaudenz' use case in the documentation (especially if
'sufficient' is used), to make users aware of the importance not to
use pam_script_auth where pam_script_ses_open should be used.
I think, as Gaudenz suggests, Martijn as the maintainer should decide
which default setting he prefers. In any case and after this thorough
discussion, I agree that the 'bug' should not be the reason to not
ship the package in jessie. (I was still kind of 'shocked' by being
able to log into my test setup as root without password when I
reported the bug. Today I would probably not rate the issue as
'grave'. )
Best regards,
Andi
Hi Guys, Thanks for your responce. Would it be ok to ship with the current pam-configs/pam_script and make a note/warning in the Readme.Debian file ? Regards, Martijn van Brummelen
Hi Martijn,
I am fine with this.
Best regards,
Andi