There used to be a duo_unix [1] package in the security repo, but it was a bit out of date. I branched it and updated it to (what was) current in my home repo [2], but unfortunately the original package was deleted before I could submit my updates. Does this mean I’ll have to create a new package from scratch and then submit that to the security repo? I’ve tried to use 'osc copypac' but it just creates a new dangling link, or completely fails if I use -e.
An outstanding issue that I meant to ask this list before submitting is that Duo changed their build to statically link libduo; quoth their changelog (v1.9.20): - Link libduo statically to address issues with the ldconfig cache and incompatibilities between versions
My understanding is that this should not be an issue on openSUSE, since RPM scripts will run ldconfig as needed after installation/upgrade. (And indeed, duo_unix.spec has '%post -n %{libname} -p /sbin/ldconfig’ and likewise for %postun.) I guess they have their reasons and would not want a patch reverting that, but I should create a local patch to link libduo dynamically to comply with the SUSE packaging policies, right?
There are also some rpmlint warnings but I think these only apply if submitting to factory and not for the OBS security repo, right? (Although having the security team review it and getting Duo included might be good things…) ==== - pam_duo.x86_64: W: suse-pam-unauthorized-module pam_duo.so
- duo_unix.x86_64: E: permissions-unauthorized-file (Badness: 100) /etc/permissions.d/duo_unix - That file has a commented-out line for applying 4755 (setuid) to login_duo, which is normally not used on Linux (pam_duo is used instead)
- duo_unix.x86_64: W: missing-call-to-setgroups-before-setuid /usr/sbin/login_duo This executable is calling setuid and setgid without setgroups or initgroups. There is a high probability this means it didn't relinquish all groups, and this would be a potential security issue to be fixed. Seek POS36-C on the web for details about the problem. ==== I think the last one is a false positive since it doesn’t want to change supplementary groups (not to mention root doesn’t generally have any) and does call setgid() before setuid() [3].
But is there any reason to put pam_duo in a separate package, as whoever previously maintained this in OBS did? Duo’s repositories for e.g. Red Hat or Ubuntu just have a single duo_unix package. Obviously a separate -devel package and libduo3 make sense, but I’m not finding anything requiring this for PAM modules.
Thanks,
Andrew Daugherity | Systems Administrator II Technology Services – Research Technologies Texas A&M University College Station, TX 77843-1112
[1] https://github.com/duosecurity/duo_unix [2] https://build.opensuse.org/package/show/home:adaugherity:branches:security/d... [3] https://github.com/duosecurity/duo_unix/blob/6c1abc27390cc4461757cf494e1cb13...
On Jan 20 2023, Daugherity, Andrew W wrote:
There used to be a duo_unix [1] package in the security repo, but it was a bit out of date. I branched it and updated it to (what was) current in my home repo [2], but unfortunately the original package was deleted before I could submit my updates. Does this mean I’ll have to create a new package from scratch and then submit that to the security repo? I’ve tried to use 'osc copypac' but it just creates a new dangling link, or completely fails if I use -e.
Since you already branched it you can recover it by removing the _link file in your branched package.
On Jan 23, 2023, at 3:46 AM, Andreas Schwab <schwab@suse.demailto:schwab@suse.de> wrote:
On Jan 20 2023, Daugherity, Andrew W wrote:
There used to be a duo_unix [1] package in the security repo, but it was a bit out of date. I branched it and updated it to (what was) current in my home repo [2], but unfortunately the original package was deleted before I could submit my updates. Does this mean I’ll have to create a new package from scratch and then submit that to the security repo? I’ve tried to use 'osc copypac' but it just creates a new dangling link, or completely fails if I use -e.
Since you already branched it you can recover it by removing the _link file in your branched package.
-- Andreas Schwab, SUSE Labs, schwab@suse.demailto:schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different.”
Thanks for the tip! It didn’t work with 'osc rm _link' but I was able to remove it via the web interface and then continue development.
I’ve now implemented basically everything I proposed, and submitted it as #1063920.
-Andrew
-
Andreas Schwab -
Daugherity, Andrew W