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.
-- Eli Schwartz Bug Wrangler and Trusted User