Bugzilla – Bug 1081947
PAM module pam_keyinit is still not integrated in the SUSE PAM stack
Last modified: 2022-11-15 14:31:24 UTC
Bug #1045886 revealed the lack of the integration of the PAM module "pam_keyinit". The pam_keyinit PAM module ensures that the invoking process has a session keyring other than the user default session keyring. The created session keyring will be linked to the user keyring. Even if it currently works without the integration of "pam_keyinit", in this case the user session keyring is used as fallback, it's strongly recommended to use a session-keyring instead especially for root user, see man user-session-keyring(7). That would also has the benefit to re-enable the keyring support in systemd where each system service gets its own session keyring automatically not linked with the user-keyring (the root one). pam-config gained support for the configuration of pam_keyinit recently [1] but it's still not used and therefore pam_keyinit is still not integrated in the PAM stack. [1] https://build.opensuse.org/request/show/565816
Josef, as PAM maintainer, I'm assigning this bug to you. Feel free to reassign if this appears to be a wrong choice. Thanks.
I can't reproduce: 1) when building the current version of pam (1.3.0-0), pam_keyinit.so is there: /lib64/security/pam_keyinit.so 2) when I install pam (1.1.8-14.1) on a Tumbleweed machine, it's there: /lib64/security/pam_keyinit.so Which package version are you using? Can you attach a supportconfig of the system?
It's not about pam_keyinit not built, the problem is that the module is not integrated in the stack: $ grep -r pam_keyinit /etc/pam.d <nothing> Thanks.
Thorsten, can you please look at this? Thanks.
Re comment #3: Why should it be in the stack? It needs to be added explicitly by calling pam-config with appropriate parameters (eg "pam-config --service vnc -a --keyinit"). The lengthy discussion in Bug #1045886 shows that it would not be advisable to just automatically add pam_keyinit to pam config files! The infrastructure is there, it just needs to be used.
(In reply to Josef Möllers from comment #6) > Re comment #3: > Why should it be in the stack? where else would you want to it to be ? The kernel keyring stuff is a general infra provided by the kernel which needs special care during session creation so that all applications can rely on it if needed. > The lengthy discussion in Bug #1045886 shows that it would not be advisable > to just automatically add pam_keyinit to pam config files! what did you make think so ?
(In reply to Franck Bui from comment #7) > (In reply to Josef Möllers from comment #6) > > Re comment #3: > > Why should it be in the stack? > > where else would you want to it to be ? But how should it end up there? AFAIK the only way is to explicitly call pam-config! > The kernel keyring stuff is a general infra provided by the kernel which > needs special care during session creation so that all applications can rely > on it if needed. > > > The lengthy discussion in Bug #1045886 shows that it would not be advisable > > to just automatically add pam_keyinit to pam config files! > > what did you make think so ? The quote from "man pam_keyinit": "This module should not, generally, be invoked by programs like su, since it is usually desirable for the key set to percolate through to the alternate context. The keys have their own permissions system to manage this." An idea in the discussion had been to write some rpmlint-skript which would force the maintaines to include pam_keyinit into their pam config files. But I can only guess howone would do that.
(In reply to Josef Möllers from comment #8) > (In reply to Franck Bui from comment #7) > > (In reply to Josef Möllers from comment #6) > > > Re comment #3: > > > Why should it be in the stack? > > > > where else would you want to it to be ? > > But how should it end up there? AFAIK the only way is to explicitly call > pam-config! > Not for basic/core modules. AFAICS by default /etc/pam.d/common-session contains: > session required pam_limits.so > session required pam_unix.so try_first_pass > session optional pam_umask.so > session optional pam_env.so > session optional pam_systemd.so IIUC none of these modules rely on an external package to set them up. And I just realized that even pam_systemd is part of this "core" list... I didn't know that and I guess the use of "pam-config" in systemd.spec becomes useless... Perhaps you should have a look at how other distros made it ?
(In reply to Franck Bui from comment #9) > Perhaps you should have a look at how other distros made it ? BTDT! Other distributions have two sets of common-* and module-specific files: one set *with* "force" and one set *without* "force" and the commands need to load the appropriate module-specific file: i.e. if run with "-i", "sudo" must load "/etc/pam.d/sudo-i" which includes "common-session-force" and if run without "-i" it must load "/etc/pam.d/sudo" which includes "common-session". Then "pam" would ship with both sets of common-* files. This requires a number of packages to be modified: gdm, util-linux, xorg-x11-server, sudo, openssh, to name but a few. I have found no way to automagically detect the requirement of "force".
Hi Stanislav, Can you please include pam_keyinit.so in the pam.d config files? It should be inserted at the top of * su-l WITH "force" (ie "session optional pam_keyinit.so force revoke") * runuser WITHOUT "force" (ie "session optional pam_keyinit.so revoke") * runuser-l WITH "force" (ie "session optional pam_keyinit.so force revoke") NB "su" doesn't need it. When you're finished, please re-assign back to me so I can trigger others. Thanks.
Ping Stanislav
Is it a request for Tumbleweed only, or should it be done for Leap 15 & SLE 15 as well? And additional question: pam files are %config(noreplace). The default behavior of rpm: If the file is not changed, use the new copy. If the file was changed, save new copy as foo.rpmnew and keep the old instance active. If you want to force the line into user customized pam files, you would need a special %post hacks.
(In reply to Stanislav Brabec from comment #13) > Is it a request for Tumbleweed only, or should it be done for Leap 15 & SLE > 15 as well? Yes. Although the request is for TW, it should be included in all future versions of SLE. > And additional question: > > pam files are %config(noreplace). The default behavior of rpm: If the file > is not changed, use the new copy. If the file was changed, save new copy as > foo.rpmnew and keep the old instance active. > > If you want to force the line into user customized pam files, you would need > a special %post hacks. I don't think that would be necessary. Thanks.
Josef Möllers, comment 14: > (In reply to Stanislav Brabec from comment #13) > > Is it a request for Tumbleweed only, or should it be done for Leap 15 & SLE > > 15 as well? > > Yes. Although the request is for TW, it should be included in all future versions of SLE. Does this include a change of SLE 15 GA? If yes, I will submit it there. If not, please open/clone this bug for SLE 15 SP1 (it is not yet clean, whether SLE 15 SP1 will inherit util-linux from GA or Tumbleweed).
(In reply to Stanislav Brabec from comment #15) > Josef Möllers, comment 14: > > (In reply to Stanislav Brabec from comment #13) > > > Is it a request for Tumbleweed only, or should it be done for Leap 15 & SLE > > > 15 as well? > > > > Yes. Although the request is for TW, it should be included in all future versions of SLE. > > Does this include a change of SLE 15 GA? If yes, I will submit it there. If > not, please open/clone this bug for SLE 15 SP1 (it is not yet clean, whether > SLE 15 SP1 will inherit util-linux from GA or Tumbleweed). Yes, please submit to SLE 15! Josef
Please review: https://build.opensuse.org/request/show/596006 The relevant change only: https://build.opensuse.org/package/rdiff/home:sbrabec:branches:util-linux-b1081947/util-linux?linkrev=base&rev=3
(In reply to Stanislav Brabec from comment #17) > Please review: > https://build.opensuse.org/request/show/596006 > > The relevant change only: > https://build.opensuse.org/package/rdiff/home:sbrabec:branches:util-linux- > b1081947/util-linux?linkrev=base&rev=3 Looks fine to me. One little issue: you refer to su.pamd in the changes files but haven't actually changed it (which is OK).
Hello Krystina, As you can see from the comments 11 and following, pam_keyinit.so must be added to the sudo configuration: * in the "sudo -l" case, "force must be specified * in the "sudo" case, no "force" must be specified. My understanding is that 1) a "sudo-l" file should be created in "/etc/pam.d" with the same contents as "/etc/pam.d/sudo" PLUS the line "session optional pam_keyinit.so force revoke" 2) plugins/sudoers/defaults.c must be changed as to use that file for def_pam_login_service. Please make the changes ASAP (if possible for SLE-15), then clear NEEDINFO and assign back to me. Any questions -> welcome! Dĕkuji! Josef
(In reply to Josef Möllers from comment #20) > Hello Krystina, > > As you can see from the comments 11 and following, pam_keyinit.so must be > added to the sudo configuration: > * in the "sudo -l" case, "force must be specified > * in the "sudo" case, no "force" must be specified. You probably mean "sudo -i". > My understanding is that > 1) a "sudo-l" file should be created in "/etc/pam.d" with the same contents > as "/etc/pam.d/sudo" PLUS the line "session optional pam_keyinit.so force > revoke" Yes, and the line "session optional pam_keyinit.so revoke" should be added to the original "/etc/pam.d/sudo" file. > 2) plugins/sudoers/defaults.c must be changed as to use that file for > def_pam_login_service. It seems that this is not needed. Upstream added the support for a sudo-i pam.d file [1] while ago. So we just need to build it with "--with-pam-login" option. > Please make the changes ASAP (if possible for SLE-15), then clear NEEDINFO > and assign back to me. Please review my OBS request. If it's ok then I will send it also to SLE15. OBS request: https://build.opensuse.org/request/show/597150 The relevant change only: https://build.opensuse.org/package/rdiff/home:kstreitova:branches:Base:System/sudo?linkrev=base&rev=3 Thanks! [1] https://www.sudo.ws/repos/sudo/rev/06d34f16520b
The changes are OK. Thanks and please assign back to me.
(In reply to Josef Möllers from comment #23) > The changes are OK. > Thanks and please assign back to me. Ok, submitted for sudo in: | Codestream | Request | |------------------|---------| | openSUSE:Factory | #597343 | | SUSE:SLE-15:GA | #162078 | I'm assigning it back to you.
Hello Petr, you're next in line ;-) Can you please add pam_keyinit.so to the sshd PAM config file? Just add the line session optional pam_keyinit.so force revoke Please re-assign back to me when you're done. Thanks.
Petr, if you finish this next week (23rd to 27th), can you please assign the bug to Dominique Leuenberger <dimstar@opensuse.org> for appropriate changes to gdm? I will be out-of-office during the week with no access to company emails. Thanks
Ping Petr Cerny.
Hello Dominique, As Petr does not respond, can you please make appropriate changes to gdm and re-assign back to me (or to Petr)? Thanks,
Ping Dominique.
Pingping Dominique!
(In reply to Josef Möllers from comment #31) > Pingping Dominique! Pfft - what a long bug - Just a hint for next time you have some multi-package touching stuff: make a meta-bug and children bugs relevant to each of the packages you want changed; also helps you get things done in parallel. As for gdm: There are currently four (well, 3, one is a link) pam files installed: -rw-r--r-- 1 root root 293 Jul 3 17:57 gdm -rw-r--r-- 1 root root 363 Jul 3 17:57 gdm-autologin -rw-r--r-- 1 root root 223 Jul 3 17:57 gdm-launch-environment lrwxrwxrwx 1 root root 3 Jul 3 17:57 gdm-password -> gdm I assume you want/need "session optional pam_keyinit.so force revoke" gdm/gdm-autologin and gdm-password, and without force in gdm-launch-environment? Or force not needed in any of them?
for reference: on Fedora, all seem to be using 'force' - so I'll do the same for Tumbleweed
(In reply to Dominique Leuenberger from comment #33) > for reference: on Fedora, all seem to be using 'force' - so I'll do the same > for Tumbleweed Likewise Ubuntu, I was just about to write that ;-) OK, thanks. And ... as to the "meta-bug" and "children": Never been there, never done that, but I'll keep that in mind. Thanks.
Submitted fix to the devel project: 625409 State:review By:dimstar When:2018-07-26T11:53:03 submit: home:dimstar:branches:GNOME:Factory/gdm@2 -> GNOME:Factory Review by User is new: gnome-review-bot Review by Group is new: gnome-maintainers Descr: - Enable pam_keyinit module (boo#1081947). => Back to Josef for tracking purposes
SUSE-SU-2018:2771-1: An update that solves one vulnerability and has two fixes is now available. Category: security (moderate) Bug References: 1081947,1103093,1103737 CVE References: CVE-2018-14424 Sources used: SUSE Linux Enterprise Module for Desktop Applications 15 (src): gdm-3.26.2.1-13.9.1
openSUSE-SU-2018:2818-1: An update that solves one vulnerability and has two fixes is now available. Category: security (moderate) Bug References: 1081947,1103093,1103737 CVE References: CVE-2018-14424 Sources used: openSUSE Leap 15.0 (src): gdm-3.26.2.1-lp150.11.3.1
I'll add the pam_keyinit.so to the PAM config file: session optional pam_keyinit.so force revoke Will be submitted soon.
We submitted the openSSH with this to Tumbleweed and SLE will also get it in update. -> reassigning back.
That should fix this, then.
SUSE-SU-2018:3686-1: An update that solves two vulnerabilities and has three fixes is now available. Category: security (moderate) Bug References: 1081947,1091396,1105010,1106163,964336 CVE References: CVE-2018-15473,CVE-2018-15919 Sources used: SUSE Linux Enterprise Module for Server Applications 15 (src): openssh-7.6p1-9.3.1 SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src): openssh-7.6p1-9.3.1 SUSE Linux Enterprise Module for Desktop Applications 15 (src): openssh-askpass-gnome-7.6p1-9.3.1 SUSE Linux Enterprise Module for Basesystem 15 (src): openssh-7.6p1-9.3.1
openSUSE-SU-2018:3801-1: An update that solves two vulnerabilities and has three fixes is now available. Category: security (moderate) Bug References: 1081947,1091396,1105010,1106163,964336 CVE References: CVE-2018-15473,CVE-2018-15919 Sources used: openSUSE Leap 15.0 (src): openssh-7.6p1-lp150.8.3.1, openssh-askpass-gnome-7.6p1-lp150.8.3.1
(In reply to Stanislav Brabec from comment #17) > Please review: > https://build.opensuse.org/request/show/596006 > > The relevant change only: > https://build.opensuse.org/package/rdiff/home:sbrabec:branches:util-linux- > b1081947/util-linux?linkrev=base&rev=3 I believe this ended up to the following commit: https://build.opensuse.org/package/rdiff/Base:System/util-linux?linkrev=base&rev=372 If so, you forgot to add pam_keyinit in /etc/pam.d/login too. Can you please do so ? Thanks.
Done: https://build.opensuse.org/request/show/680184 Could you verify that it is correct? I will submit the change to SLE 15 SP1. Should I add this to the next update in SLE 15?
(In reply to Stanislav Brabec from comment #52) > Done: https://build.opensuse.org/request/show/680184 > > Could you verify that it is correct? > According to pam_keyring man page: This module should be included as early as possible in a PAM configuration, so that other PAM modules can attach tokens to the keyring. Therefore I would put it earlier in the list, ie before "common-session". > I will submit the change to SLE 15 SP1. > > Should I add this to the next update in SLE 15? The most important distro to fix is Factory/Tumbleweed at the moment since we're planning to re-introduce the keyring mode stuff in systemd soon. As far as SLE15+ is concerned, it's not strictly mandatory since we don't plan to re-enable the keyring stuff but it shouldn't hurt either. I think if you add it to SLE15-SP1, it also makes sense to submit it to SLE15 especially if other packages did it already.
Thanks, request was updated: https://build.opensuse.org/request/show/680624 Last question: We have also remote.pamd. It is used by login for remote logins (i. e. logins from terminals that are not recognized as local). Should I add pam_keyinit support there as well?
(In reply to Stanislav Brabec from comment #54) > Thanks, request was updated: > https://build.opensuse.org/request/show/680624 > Other distros tend to put pam_keyinit below pam_loginuid. > Last question: > We have also remote.pamd. It is used by login for remote logins (i. e. > logins from terminals that are not recognized as local). > > Should I add pam_keyinit support there as well? Well not sure but I don't see any reason why a user shouldn't have a new session keyring setup if he logs in via telnelt (for example).
Josef, It seems there are packages which are still missing the pam_keyinit module: sddm, xdm, enlightment... And before you ask, I don't know how to get an exhaustive list of the remaining packages ;) But if we miss one package and the session keyring stuff in systemd is enabled (which is not the case currently) we may end up with a security issue like the one described in boo#1045886 comment #20 :-/ And given that how pam_keyinit is added in each package, I don't see how we can be certain that we won't miss one.
(In reply to Franck Bui from comment #56) > Josef, > > It seems there are packages which are still missing the pam_keyinit module: > sddm, xdm, enlightment... Martin Wilck had quite an impressive list of packages/programs in https://bugzilla.opensuse.org/show_bug.cgi?id=1045886#c23 > And before you ask, I don't know how to get an exhaustive list of the > remaining packages ;) > > But if we miss one package and the session keyring stuff in systemd is > enabled (which is not the case currently) we may end up with a security > issue like the one described in boo#1045886 comment #20 :-/ > > And given that how pam_keyinit is added in each package, I don't see how we > can be certain that we won't miss one. The main problem is that we can't just add it to common-session, as it will then be invoked by programs that MUST NOT use it. What's more: some programs need different invocations based upon their arguments: "sudo" should call it without "force", "sudo -i" should call it with "force"! The same applies to "runuser" and the "-l" flag. NB I've looked at fedora and ubuntu and both have the invocation in the programs' configuration files, too. So each package that needs it MUST individually include it with arguments specific to its use and we can't rely on pam-config to do The Right Thing, as it only writes the common-xxx files. Other than posting on research@suse.de I, too, have no idea how to get a complete list. I'm not sure if searching all packages for including an /etc/pam.d configuration file is feasible. And even then, one would have to search through that list to find all that need pam_keyinit.so. Maybe we should put in some "physical" brainstorming session in week 13 and try to include (at least) Werner Fink and Thorsten Kukuk.
I am going to prepare SLE12 SP5 package of util-linux. Should I add these fixes there, as the sudo submit indicates (internal comment 59)?
For now I would have done that for Factory only. Maybe once we were sure that everything worked properly and no regressions had been reported we could have considered backporting it to SLE through a new SP release.
I am just preparing a big util-linux update for all released products. I realized that session optional pam_keyinit.so force revoke is already present in SLE-15:Update and SLE-15-SP1:Update. But it is in an inconsistent state. This one is included: Thu Apr 12 17:09:30 CEST 2018 - sbrabec@suse.com - Integrate pam_keyinit pam module (boo#1081947, su-l.pamd, runuser-l.pamd, runuser.pamd). This one is not included: Mon Mar 4 15:23:27 CET 2019 - sbrabec@suse.com - Integrate pam_keyinit pam module to login (boo#1081947, login.pamd, remote.pamd). I would like to see it in a consistent state. What do you recommend for SLE-15:Update and SLE-15-SP1:Update? 1) Remove pam_keyinit integration from all files? 2) Add pam_keyinit consistently to all pam files?
(In reply to Stanislav Brabec from comment #62) > I am just preparing a big util-linux update for all released products. > > I realized that > session optional pam_keyinit.so force revoke > is already present in SLE-15:Update and SLE-15-SP1:Update. > > But it is in an inconsistent state. > > This one is included: > > Thu Apr 12 17:09:30 CEST 2018 - sbrabec@suse.com > - Integrate pam_keyinit pam module (boo#1081947, su-l.pamd, > runuser-l.pamd, runuser.pamd). > > This one is not included: > > Mon Mar 4 15:23:27 CET 2019 - sbrabec@suse.com > - Integrate pam_keyinit pam module to login > (boo#1081947, login.pamd, remote.pamd). > > > I would like to see it in a consistent state. What do you recommend for > SLE-15:Update and SLE-15-SP1:Update? > 1) Remove pam_keyinit integration from all files? I would vote against removing it completely as it doesn't do any damage if it is there (it just creates a small kernel-data structure) and this would undo the work already done. The files where it IS included are correct in their use, see below. > 2) Add pam_keyinit consistently to all pam files? You can't add "pam_keyinit" to all PAM config files as this might create a keyring when you don't want one and even may dispose of the old one, which is not what you want. Also the options differ between types of invocation: some require "force" (eg "sudo -i" or "su -l"), some must not have this option (eg "sudo" without "-l", "su" without "-l"). I'm currently working on a list of 57 packages to find out which ones need pam_keyinit and which ones need "force". It's a tedious activity.
Well, in case of util-linux in Factory, all its files have pam_keyinit and they should have it. Se bugs referred in the comment 62. Regarding SLE15 and SLE15 SP1: We already have pam_keyinit support there from boo#1081947. I want to know, whether I should backport boo#1081947 as well, so its support will be complete. Or should I postpone the second bug fix e. g. to SLE15 SP2. Note to comment 60: While backporting util-linux from Factory to SLE12 SP5, I deleted pam_keyinit support from all files. And a special note: Many pam files are tagged as noreplace. In this case, its fix in the package does not mean, that it will be fixed on upgrade. We need a special action for that. See bug 1082293 as an example. I just made a fix for that: oneshot reset of the config file. Once tested, I will provide the implementation here.
Josef Möllers: Could you provide an answer, please? su, su -l, runuser and runuser -l already have pam_keyinit support in both SLE15 and SLE15 SP1. That is why I think that we can finish (i. e. make consistent) the pam_keyinit support in util-linux by backporting of: Mon Mar 4 15:23:27 CET 2019 - sbrabec@suse.com - Integrate pam_keyinit pam module to login (boo#1081947, login.pamd, remote.pamd). But maybe there are some reasons not to do it, even if su, su -l, runuser and runuser -l already support it.
(In reply to Stanislav Brabec from comment #65) > Josef Möllers: Could you provide an answer, please? > > su, su -l, runuser and runuser -l already have pam_keyinit support in both > SLE15 and SLE15 SP1. That is why I think that we can finish (i. e. make > consistent) the pam_keyinit support in util-linux by backporting of: > > Mon Mar 4 15:23:27 CET 2019 - sbrabec@suse.com > - Integrate pam_keyinit pam module to login > (boo#1081947, login.pamd, remote.pamd). > > But maybe there are some reasons not to do it, even if su, su -l, runuser > and runuser -l already support it. No, there are no reasons not to do it. 1) Integrating it doesn't cause any problems: a small kernel data structure (a "key ring")is allocated which, AT PRESENT, is unused but will be used in the future 2) Eventually every package which should support it MUST support it to have consistency: programs accessing the key rings must be able to find it. So, each package supporting pam_keyinit is a step towards the final goal: full support of kernel keyrings.
OK, thanks. I will add pam_keyinit to login and remote.
Important note to all package maintainers who use %config(noreplace) /etc/pam.d/foo If you use this, pam_keyinit will not be integrated on upgrade of systems with custom modifications of the PAM file. I recommend to use: %config /etc/pam.d/foo Note: Most RPM documentation doesn't say true about "%config". Following is correct: %config(noreplace) If the old and new packaged config files have the same MD5: Installed file is left as it is, update is completely skipped. If the old and new packaged config files have different MD5: Installed file is left as it is and .rpmnew file with a new packaged contents is created. %config If the old and new packaged config files have the same MD5: Installed file is left as it is, update is completely skipped. If the old and new packaged config files have different MD5: Installed file is replaced and .rpmorig file with the previous installed file is created. It implies: 1) %config /etc/pam.d/foo is what most maintainers want: - If the package maintainer does not change the pam file, custom modifications are kept forever. - If the package maintainer changes the pam file, custom modification are removed (and backed up) in favor of the new contents. 2) If you integrate pam_keyinit first and later remove "(noreplace)", and these changes are installed by two steps on a system with custom modifications, then the custom modifications are kept forever, and pam_keyinit is not integrated. A simple work around: Together with removal of "(noreplace)", do pam files modification (e. g. use "expand" command, change number of spaces or so).
(In reply to Stanislav Brabec from comment #68) > Important note to all package maintainers who use > %config(noreplace) /etc/pam.d/foo > > If you use this, pam_keyinit will not be integrated on upgrade of systems > with custom modifications of the PAM file. Correct, like with all other configuration files. > I recommend to use: > %config /etc/pam.d/foo util-linux contains the PAM configurations files, which users most of time always have to adjust (login, su, etc.) for their needs. So everytime, where you overwrite the users PAM configuration file with a default, in worst case, the user cannot login anymore! This is really a bad idea. > It implies: > 1) %config /etc/pam.d/foo > is what most maintainers want: Correct, what maintainers like (or want), but clearly not what customers want. Everytime we overwrite a customer PAM configuration (even if we create a backup), we have immediately escalations and L3s.
Thorsten Kukuk: So what solutions your propose? If we use noreplace, that we will get bug reports like "pam_keyinit not integrated after upgrade" or "last login shown twice" (bug 1082293). I can imagine: a) Remove "noreplace". Allow PAM file change only for new products or service packs. Prohibit any packaged PAM file changes in online updates, so online update will never overwrite PAM file, but new product release or migration can do it. (Easy to do, but my recent online update has to be redone.) b) Keep "noreplace" and risk side-effects of outdated PAM files (e. g. bug 1082293 will be closed as RESOLVED INVALID). Maybe report the existing backup to the console. (Easy to do it.) c) Keep "noreplace" and track all PAM file changes back to the beginning of the "noreplace" history, and provide a special migration %post that makes required. (Complicated, as it requires digging into old releases.) Example: if grep "^auth.*default=bad.*pam_securetty\\.so" /etc/pam.d/login ; then sed -i "/^auth.*default=bad.*pam_securetty\\.so/d" /etc/pam.d/login fi if ! grep "^session.*pam_keyinit\\.so" /etc/pam.d/login ; then echo "session optional pam_keyinit.so force revoke" >>/etc/pam.d/login fi etc. d) Invent a special check/tool that can track pam file changes. I was working on a check that will trigger build failure whenever PAM file is changed and migration script is not made. I can finish it and make a RPM macro for that. (Also complicated, as it requires digging into old releases, but once it will be done, it will be safe for future.)
(In reply to Stanislav Brabec from comment #74) > Thorsten Kukuk: So what solutions your propose? > > If we use noreplace, that we will get bug reports like "pam_keyinit not > integrated after upgrade" or "last login shown twice" (bug 1082293). And if you don't use "noreplace", you will get a lot of L3 from angry customers, who are no longer able to login. > I can imagine: > > a) Remove "noreplace". Allow PAM file change only for new products or > service packs. Prohibit any packaged PAM file changes in online updates, so > online update will never overwrite PAM file, but new product release or > migration can do it. (Easy to do, but my recent online update has to be > redone.) So if you have a security problem like pam_keyinit is missing, you cannot fix it? > b) Keep "noreplace" and risk side-effects of outdated PAM files (e. g. bug > 1082293 will be closed as RESOLVED INVALID) That's what we normally do in such cases, yes. > c) Keep "noreplace" and track all PAM file changes back to the beginning of > the "noreplace" history, and provide a special migration %post that makes > required. (Complicated, as it requires digging into old releases.) > > Example: > if grep "^auth.*default=bad.*pam_securetty\\.so" /etc/pam.d/login ; then > sed -i "/^auth.*default=bad.*pam_securetty\\.so/d" /etc/pam.d/login > fi > if ! grep "^session.*pam_keyinit\\.so" /etc/pam.d/login ; then > echo "session optional pam_keyinit.so force revoke" > >>/etc/pam.d/login > fi > etc. This can lead very easy to broken/inscure PAM configuration files. The order of the modules ireally important. If we cannot add such modules via pam-config from a post install section, but have to modify the PAM configuration file and ship a new one, we have to live with bug reports and close them as appropriate. If people don't merge their configuration changes, close it as invalid. Between, we have a service for warning for *.rpmnew and *.rpmsave files, but it got years ago disabled. Don't know why, but most likely it did not really help.
OK. So I will not attempt to merge new pam_keyinit to existing modified PAM files at all. And similarly, I should not try to attempt to delete items that are deleted from the default. So the following is the best we can do: if grep "^auth.*default=bad.*pam_securetty\\.so" /etc/pam.d/login ; then echo "Your /etc/pam.d/login contains pam_securetty, which is now considered as obsolete. See /etc/pam.d/login.rpmnew." fi if ! grep "^session.*pam_keyinit\\.so" /etc/pam.d/login ; then echo "Your /etc/pam.d/login needs pam_keyinit integration. See /etc/pam.d/login.rpmnew." By the way: It would be nice to store a backup of packaged versions of all %config* files. It would make possible three way merge. Note that Tumbleweed contains etc-update tool.
This is an autogenerated message for OBS integration: This bug (1081947) was mentioned in https://build.opensuse.org/request/show/721380 Factory / util-linux
This is an autogenerated message for OBS integration: This bug (1081947) was mentioned in https://build.opensuse.org/request/show/721594 Factory / util-linux
Here is my new solution. It just displays warning and nothing more. I see no safe way to do automatic integration to the customer edited file. # If outdated PAM file is detected, issue a warning. for PAM_FILE in login remote runuser runuser-l su su-l ; do if test -f %{_sysconfdir}/pam.d/$PAM_FILE.rpmnew ; then echo "Your %{_sysconfdir}/pam.d/$PAM_FILE is outdated. Please check %{_sysconfdir}/pam.d/$PAM_FILE.rpmnew!" >&2 fi done
SUSE-SU-2019:2307-1: An update that contains security fixes can now be installed. Category: security (moderate) Bug References: 1081947,1082293,1085196,1106214,1121197,1122417,1125886,1127701,1135534,1135708,1141113,353876 CVE References: Sources used: SUSE Linux Enterprise Module for Server Applications 15-SP1 (src): util-linux-systemd-2.33.1-4.5.1 SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src): python3-libmount-2.33.1-4.5.1, util-linux-2.33.1-4.5.1 SUSE Linux Enterprise Module for Basesystem 15-SP1 (src): shadow-4.6-3.5.6, util-linux-2.33.1-4.5.1, util-linux-systemd-2.33.1-4.5.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
openSUSE-SU-2019:2121-1: An update that contains security fixes can now be installed. Category: security (moderate) Bug References: 1081947,1082293,1085196,1106214,1121197,1122417,1125886,1127701,1135534,1135708,1141113,353876 CVE References: Sources used: openSUSE Leap 15.1 (src): python3-libmount-2.33.1-lp151.3.3.2, shadow-4.6-lp151.2.3.2, util-linux-2.33.1-lp151.3.3.2, util-linux-systemd-2.33.1-lp151.3.3.2
SUSE-RU-2019:2363-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1081947,1144047 CVE References: Sources used: SUSE Linux Enterprise Module for Server Applications 15 (src): krb5-1.15.2-6.9.1 SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src): krb5-mini-1.15.2-6.9.1 SUSE Linux Enterprise Module for Basesystem 15 (src): krb5-1.15.2-6.9.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-RU-2019:2361-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1081947,1144047 CVE References: Sources used: SUSE Linux Enterprise Module for Server Applications 15-SP1 (src): krb5-1.16.3-3.6.1 SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src): krb5-1.16.3-3.6.1, krb5-mini-1.16.3-3.6.1 SUSE Linux Enterprise Module for Basesystem 15-SP1 (src): krb5-1.16.3-3.6.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
(In reply to Stanislav Brabec from comment #68) > Important note to all package maintainers who use > %config(noreplace) /etc/pam.d/foo > > If you use this, pam_keyinit will not be integrated on upgrade of systems > with custom modifications of the PAM file. > > > I recommend to use: > %config /etc/pam.d/foo > > Note: Most RPM documentation doesn't say true about "%config". Following is > correct: > > %config(noreplace) > > If the old and new packaged config files have the same MD5: > Installed file is left as it is, update is completely skipped. > > If the old and new packaged config files have different MD5: > Installed file is left as it is and .rpmnew file with a new packaged contents > is created. > > > %config > If the old and new packaged config files have the same MD5: > Installed file is left as it is, update is completely skipped. > > If the old and new packaged config files have different MD5: > Installed file is replaced and .rpmorig file with the previous installed file > is created. > > > It implies: > 1) %config /etc/pam.d/foo > is what most maintainers want: > > - If the package maintainer does not change the pam file, custom > modifications are kept forever. > - If the package maintainer changes the pam file, custom modification are > removed (and backed up) in favor of the new contents. > > 2) If you integrate pam_keyinit first and later remove "(noreplace)", and > these changes are installed by two steps on a system with custom > modifications, then the custom modifications are kept forever, and > pam_keyinit is not integrated. > > A simple work around: Together with removal of "(noreplace)", do pam files > modification (e. g. use "expand" command, change number of spaces or so). The fix was not present in https://build.suse.de/request/show/199906 https://build.suse.de/request/show/199904 https://build.suse.de/request/show/199905 grep -r pam_keyinit /etc/pam.d yields no output In contrast, eg for https://build.suse.de/request/show/200156 the issue is fixed: grep -r pam_keyinit /etc/pam.d shows the various entries of pam_keyinit.so in the pam.d files
openSUSE-RU-2019:2144-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1081947,1144047 CVE References: Sources used: openSUSE Leap 15.1 (src): krb5-1.16.3-lp151.2.6.1, krb5-mini-1.16.3-lp151.2.6.1
SUSE-SU-2019:2392-1: An update that contains security fixes can now be installed. Category: security (moderate) Bug References: 1081947,1082293,1085196,1106214,1121197,1122417,1125886,1135534,1135708,353876 CVE References: Sources used: SUSE Linux Enterprise Module for Server Applications 15 (src): util-linux-systemd-2.31.1-9.8.1 SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src): python-libmount-2.31.1-9.8.1 SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src): python-libmount-2.31.1-9.8.1, util-linux-2.31.1-9.8.1 SUSE Linux Enterprise Module for Basesystem 15 (src): shadow-4.5-7.6.4, util-linux-2.31.1-9.8.1, util-linux-systemd-2.31.1-9.8.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
openSUSE-SU-2019:2175-1: An update that contains security fixes can now be installed. Category: security (moderate) Bug References: 1081947,1082293,1085196,1106214,1121197,1122417,1125886,1135534,1135708,353876 CVE References: Sources used: openSUSE Leap 15.0 (src): shadow-4.5-lp150.11.2, util-linux-2.31.1-lp150.7.10.2
openSUSE-RU-2019:2167-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1081947,1144047 CVE References: Sources used: openSUSE Leap 15.0 (src): krb5-1.15.2-lp150.5.10.1
George Gkioulis, comment 90: It is correct. SLE 12 does not support pam_keyinit.
All packages which require pam_keyinit have been modified and the SRs have been accepted.
openSUSE-RU-2020:0918-1: An update that has two recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1081947,1144047 CVE References: Sources used: openSUSE Leap 15.2 (src): krb5-1.16.3-lp152.5.3.1, krb5-mini-1.16.3-lp152.5.4.1
SUSE-SU-2021:3463-1: An update that solves one vulnerability and has 19 fixes is now available. Category: security (moderate) Bug References: 1081947,1082293,1084671,1085196,1106214,1122417,1125886,1135534,1135708,1151708,1168235,1168389,1169006,1174942,1175514,1175623,1178236,1178554,1178825,1188921 CVE References: CVE-2021-37600 JIRA References: Sources used: SUSE OpenStack Cloud Crowbar 8 (src): python-libmount-2.29.2-3.24.1, util-linux-2.29.2-3.24.1, util-linux-systemd-2.29.2-3.24.1 SUSE OpenStack Cloud 8 (src): python-libmount-2.29.2-3.24.1, util-linux-2.29.2-3.24.1, util-linux-systemd-2.29.2-3.24.1 SUSE Linux Enterprise Server for SAP 12-SP3 (src): python-libmount-2.29.2-3.24.1, util-linux-2.29.2-3.24.1, util-linux-systemd-2.29.2-3.24.1 SUSE Linux Enterprise Server 12-SP3-LTSS (src): python-libmount-2.29.2-3.24.1, util-linux-2.29.2-3.24.1, util-linux-systemd-2.29.2-3.24.1 SUSE Linux Enterprise Server 12-SP3-BCL (src): python-libmount-2.29.2-3.24.1, util-linux-2.29.2-3.24.1, util-linux-systemd-2.29.2-3.24.1 HPE Helion Openstack 8 (src): python-libmount-2.29.2-3.24.1, util-linux-2.29.2-3.24.1, util-linux-systemd-2.29.2-3.24.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2022:1103-1: An update that solves one vulnerability and has 23 fixes is now available. Category: security (important) Bug References: 1038841,1081947,1082293,1084671,1085196,1106214,1116347,1122417,1125886,1135534,1135708,1151708,1168235,1168389,1169006,1172427,1174942,1175514,1175623,1178236,1178554,1178825,1188921,1194642 CVE References: CVE-2021-37600 JIRA References: Sources used: SUSE Linux Enterprise Server 12-SP2-BCL (src): python-libmount-2.28-44.35.1, util-linux-2.28-44.35.1, util-linux-systemd-2.28-44.35.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2022:1105-1: An update that solves one vulnerability and has 21 fixes is now available. Category: security (important) Bug References: 1081947,1082293,1084671,1085196,1106214,1122417,1125886,1135534,1135708,1151708,1168235,1168389,1169006,1172427,1174942,1175514,1175623,1178236,1178554,1178825,1188921,1194642 CVE References: CVE-2021-37600 JIRA References: Sources used: SUSE OpenStack Cloud Crowbar 9 (src): python-libmount-2.29.2-9.17.1, util-linux-2.29.2-9.17.1, util-linux-systemd-2.29.2-9.17.1 SUSE OpenStack Cloud 9 (src): python-libmount-2.29.2-9.17.1, util-linux-2.29.2-9.17.1, util-linux-systemd-2.29.2-9.17.1 SUSE Linux Enterprise Server for SAP 12-SP4 (src): python-libmount-2.29.2-9.17.1, util-linux-2.29.2-9.17.1, util-linux-systemd-2.29.2-9.17.1 SUSE Linux Enterprise Server 12-SP4-LTSS (src): python-libmount-2.29.2-9.17.1, util-linux-2.29.2-9.17.1, util-linux-systemd-2.29.2-9.17.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
This is an autogenerated message for OBS integration: This bug (1081947) was mentioned in https://build.opensuse.org/request/show/970966 Factory / systemd
SUSE-RU-2022:3980-1: An update that has two recommended fixes can now be installed. Category: recommended (important) Bug References: 1081947,1201354 CVE References: JIRA References: Sources used: SUSE Linux Enterprise Workstation Extension 12-SP5 (src): util-linux-2.33.2-4.24.1 SUSE Linux Enterprise Software Development Kit 12-SP5 (src): util-linux-2.33.2-4.24.1 SUSE Linux Enterprise Server 12-SP5 (src): python-libmount-2.33.2-4.24.1, util-linux-2.33.2-4.24.1, util-linux-systemd-2.33.2-4.24.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.