All,
After the pambased defaults change, I thought I had gotten everything fixed, today scanning to server via vsftpd issued:
Feb 19 12:19:49 phoinix vsftpd[8652]: pam_warn(ftp:auth): function=[pam_sm_authenticate] flags=0 service=[ftp] terminal=[ftp] user=[sharp] ruser=[sharp] rhost=[192.168.7.20]
My question is what do I put in /etc/pam.d/vsftpd?
Looking at some of the other entries, it seems I can do something with pam_unix.so like screen:
$ cat screen auth required pam_unix.so
or
$ cat dovecot auth required pam_unix.so nullok account required pam_unix.so
Since my user (the copier) has a normal Unix account and password, is there any benefit to using the dovecot style with both "auth required" and "account required" or is the "auth required" sufficient like screen uses?
On 02/19/2019 01:29 PM, David C. Rankin wrote:
$ cat dovecot auth required pam_unix.so nullok account required pam_unix.so
I just went with the dovecot version and copied it to '/etc/pam.d/ftp' and removed the 'nullok', ftp is working again.
On 20/02/19 12:59 am, David C. Rankin wrote:
All,
After the pambased defaults change, I thought I had gotten everything fixed, today scanning to server via vsftpd issued:
Feb 19 12:19:49 phoinix vsftpd[8652]: pam_warn(ftp:auth): function=[pam_sm_authenticate] flags=0 service=[ftp] terminal=[ftp] user=[sharp] ruser=[sharp] rhost=[192.168.7.20]
My question is what do I put in /etc/pam.d/vsftpd?
May be do what sshd does:
cat /etc/pam.d/sshd
#%PAM-1.0 #auth required pam_securetty.so #disable remote root auth include system-remote-login account include system-remote-login password include system-remote-login session include system-remote-login
Amish.
Hi David,
My question is what do I put in /etc/pam.d/vsftpd?
It seems flawed that individual users, like you and me, are having to concoct /etc/pam.d files due to packages not providing them and the working default having been removed by a pambase upgrade. This is because we're not knowledgable in PAM and it's easy to create a file that allows authentication again but is too permissive. The end result is worse than the working default that pambase removed, presuambly removed with improving security in mind.
From a QA point of view, shouldn't the old pambase default be put back,
packages that lack their own /etc/pam.d identified and fixed with well-considered authentication, and then the pambase change re-released?
On 2/20/19 11:29 AM, Ralph Corderoy wrote:
Hi David,
My question is what do I put in /etc/pam.d/vsftpd?
It seems flawed that individual users, like you and me, are having to concoct /etc/pam.d files due to packages not providing them and the working default having been removed by a pambase upgrade. This is because we're not knowledgable in PAM and it's easy to create a file that allows authentication again but is too permissive. The end result is worse than the working default that pambase removed, presuambly removed with improving security in mind.
How would it be "worse", precisely? If the advice is to use a policy that matches the old "other" policy, then how exactly was security *reduced*?
From a QA point of view, shouldn't the old pambase default be put back, packages that lack their own /etc/pam.d identified and fixed with well-considered authentication, and then the pambase change re-released?
From a QA point of view, if no one found the packages which lack a policy in the several years the pambase ticket was open for, then putting a permissive policy back in place means we will, once again, never find these packages.
Given the rationale for proposing the change was specifically that such applications "should" be breaking, because they are wrong and need to ship a policy due to the lack of an explicit policy being a security concern, it seems rational to argue that it's better for applications to break in a manner that warns the user and encourages applications that are doing the wrong thing to begin with, than continue to paper over the cracks.
But perhaps you have an answer to the package maintainer's comment:
I don't know of a good way to determine when "other" is used on my system, or in aggregate across a larger number of users to avoid problems.
On 02/20/2019 11:10 AM, Eli Schwartz via arch-general wrote:
From a QA point of view, if no one found the packages which lack a policy in the several years the pambase ticket was open for, then putting a permissive policy back in place means we will, once again, never find these packages.
Well, that is somewhat a "straw-man" argument. I is rather difficult to find packages which lack a policy when (1) you don't know there is a pambase bug open or (2) that a default change to pambase is coming until things start breaking. The last note on the homepage is for "ibutf8proc>=2.1.1-3 update requires manual intervention" from July 2018.
I don't mind learning PAM, but it is horribly inconvenient when you have time-critical documents to scan for the Court that suddenly won't make it from the copier to the server any more.
Somewhere there is a fine line between what a normally adept user should be expected to know and topics that developers are working with. That was made clear when public posts to the arch-dev list were suspended.
Knowing that there are likely a number of packages that still need a policy, like vsftpd, is there somewhere we should keep a list so that packages can include the policy and an install script? Or should we just mail the maintainer directly? Doesn't seem like a bug is warranted, but I'll defer to whatever the consensus is.
On 2/22/19 11:49 PM, David C. Rankin wrote:
On 02/20/2019 11:10 AM, Eli Schwartz via arch-general wrote:
From a QA point of view, if no one found the packages which lack a policy in the several years the pambase ticket was open for, then putting a permissive policy back in place means we will, once again, never find these packages.
Well, that is somewhat a "straw-man" argument. I is rather difficult to find packages which lack a policy when (1) you don't know there is a pambase bug open or (2) that a default change to pambase is coming until things start breaking. The last note on the homepage is for "ibutf8proc>=2.1.1-3 update requires manual intervention" from July 2018.
I don't mind learning PAM, but it is horribly inconvenient when you have time-critical documents to scan for the Court that suddenly won't make it from the copier to the server any more.
Somewhere there is a fine line between what a normally adept user should be expected to know and topics that developers are working with. That was made clear when public posts to the arch-dev list were suspended.
Knowing that there are likely a number of packages that still need a policy, like vsftpd, is there somewhere we should keep a list so that packages can include the policy and an install script? Or should we just mail the maintainer directly? Doesn't seem like a bug is warranted, but I'll defer to whatever the consensus is.
For vsftpd, see https://bugs.archlinux.org/task/61746
If a package needs a pam.d policy and does not have one, this is of course a bug -- please check the bugtracker to see if one exists, and if not, submit one.
My suggestion would generally be to submit or subscribe to a bug report, and then (in order of preferred to least preferred):
- apply any workaround or installation of an upstream policy mentioned in the bug report - use the contents of the old pam.d/other as the PAM policy for the currently broken package - modify your own pam.d/other policy to revert back to the former insecure defaults, with a note to restore the stock version as soon as you're notified that the bug has been fixed
arch-general@lists.archlinux.org