Package security-misc from Whonix to Qubes

[marmarek]

Whonix has security-misc package, which is meant to be reusable across different security distributions. It would be good to include it also in Qubes. This would solve #1108 for example.

It would require:

• add Makefile.builder
• add RPM packaging too
• decide how to deal with it in Whonix templates (where that package will come from two different places)

Maybe on Debian template it should be installed directly from Whonix repository? Probably bad idea, may pull another packages, have unwanted side effects.
Any opinion @adrelanos?

[adrelanos]

Marek Marczykowski-Górecki:

• decide how to deal with it in Whonix templates (where that package will come from two different places)

I don't think this will be an issue. As long as the Qubes repository is
never ahead [plus incompatible dependencies] there should be no issue.

Maybe on Debian template it should be installed directly from Whonix repository? Probably bad idea, may pull another packages, have unwanted side effects.

The Debian template should not trust the Whonix repository.

[adrelanos]

This might be more interesting now.

• Pull request More kernel hardening was contributed.
• Would also solve Disable thumbnail previews in Nautilus (Disable thumbnail previews in file managers in SecureDrop Workstation VMs freedomofpress/securedrop-workstation#13).

[adrelanos]

QubesOS/qubes-core-agent-linux#161

/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/thunar.xml by qubes-core-agent-thunar actually causes a package file conflict.

    user@host:~$ sudo apt install qubes-core-agent-thunar 
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following NEW packages will be installed:
      qubes-core-agent-thunar
    0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
    Need to get 0 B/26.2 kB of archives.
    After this operation, 50.2 kB of additional disk space will be used.
    (Reading database ... 52500 files and directories currently installed.)
    Preparing to unpack .../qubes-core-agent-thunar_4.0.45-1+deb10u1_amd64.deb ...
    Unpacking qubes-core-agent-thunar (4.0.45-1+deb10u1) ...
    dpkg: error processing archive /var/cache/apt/archives/qubes-core-agent-thunar_4.0.45-1+deb10u1_amd64.deb (--unpack):
     trying to overwrite '/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/thunar.xml', which is also in package security-misc 3:2.9-1
    Errors were encountered while processing:
     /var/cache/apt/archives/qubes-core-agent-thunar_4.0.45-1+deb10u1_amd64.deb
    E: Sub-process /usr/bin/dpkg returned an error code (1)

[marmarek]

I've created PRs with qubes-builder integration and rpm packaging (only build tested):
Kicksecure/genmkfile#1
Kicksecure/security-misc#8

But I'm not yet sure if this is the best possible approach. I see those options:

• keep qubes-builder integration and RPM packaging in the same place - upstream repository (this is what the above PRs do)
• create separate repository for just packaging (like here: https://github.com/QubesOS/qubes-python-xcffib/) - this could use either upstream tarballs (generated by github? what about signatures?) or git submodules

The first approach is less work in total (one place to update), but since upstream is focused on Debian only, rpm packaging may desynchronize. Some of it could be mitigated by adding CI (Travis).

@adrelanos what do you think?

[adrelanos]

Creating the version file could be automated. genmkfile already has make make deb-chl-bumpup-major and a new feature of adding upstream version number into version file would be easy for me.

File Makefile.builder seems to be repetitive and being everywhere the same. I don't mind adding this file (even to all packages by Whonix) (would do so using a script).

Now the complicated part is rpm_spec/genmkfile.spec.in. What I really don't like is keeping track of all file names (%files) manually. That's one of the main reasons why genmkfile was invented. I am wondering if genmkfile could auto generate rpm_spec/genmkfile.spec.in? At first sight, looks like all of the information could be extracted from debian/control and something like

for x in $(find bin boot dev etc home lib opt sbin srv sys usr var -type f 2>/dev/null); do echo /$x ; done

could auto generate the list of file names.

Not sure about anything else such as maintainer scripts?

• in case of security-misc postinst, it's just a single relevant line: https://github.com/Whonix/security-misc/blob/master/debian/security-misc.postinst#L20
• https://github.com/Whonix/security-misc/blob/master/debian/security-misc.gconf-defaults has to be ported to rpm, but that is independent on which approach will be chosen.

keep qubes-builder integration and RPM packaging in the same place - upstream repository (this is what the above PRs do)

That would be good if we can make that work.

[In any case you might want to fork it and build Qubes from the fork so in theory a malicious upstream wouldn't leak into Qubes. The fork would at most if not all times not do any Qubes specific modifications, just for security and review. Existence of https://github.com/QubesOS/qubes-python-xcffib/ indicates you have that in mind anyhow but good to spell out for other readers.]

Having said above, do you think this is feasible?

create separate repository for just packaging (like here: https://github.com/QubesOS/qubes-python-xcffib/) - this could use either upstream tarballs (generated by github? what about signatures?) or git submodules

Also ok however could be too much work for https://phabricator.whonix.org/T709 to ever materialize.

Signed upstream tarballs for all Whonix packages already exist. Example:

https://deb.whonix.org/pool/main/s/security-misc/

https://deb.whonix.org/pool/main/s/security-misc/security-misc_3.1-1.dsc

Debian buster might be required for easy verification of the signature and extraction of the archive using dpkg-source. (But also standard files that could be verified with just anything.) (Stale/rollback gpg signatures applies just like anywhere.)

dpkg-source --require-strong-checksums --require-valid-signature -x /path/to/security-misc_3.1-1.dsc /path/to/extract/to

[marmarek]

Creating the version file could be automated. genmkfile already has make make deb-chl-bumpup-major and a new feature of adding upstream version number into version file would be easy for me.

FWIW, we do that the other way around: generate debian changelog from version file and git changelog.

Now the complicated part is rpm_spec/genmkfile.spec.in. What I really don't like is keeping track of all file names (%files) manually.

In theory it's possible to list everything with wildcard (/* or such), but it is considered bad practice.

That's one of the main reasons why genmkfile was invented. I am wondering if genmkfile could auto generate rpm_spec/genmkfile.spec.in?

Might be a good idea. Indeed I've copy&pasted significant part of it from debian/control. But the file should be committed to the repository.

* in case of security-misc postinst, it's just a single relevant line: https://github.com/Whonix/security-misc/blob/master/debian/security-misc.postinst#L20
* https://github.com/Whonix/security-misc/blob/master/debian/security-misc.gconf-defaults has to be ported to rpm, but that is independent on which approach will be chosen.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_gconf

There is also another possible issue - potential differences between Debian and Fedora (and other distributions if anyone would maintain it): different paths, different software versions. Generally it's manageable, but may require extra steps over automated genmkfile.

[adrelanos]

Marek Marczykowski-Górecki:

There is also another possible issue - potential differences between

Debian and Fedora (and other distributions if anyone would maintain it): different paths, different software versions. Generally it's manageable, but may require extra steps over automated `genmkfile`. I don't think I could maintain / bug triage / fix the Fedora package versions long term. However, as it looks now, the Fedora packaging files look really simple. So if it helps, these are already merged. Somehow I misinterpreted "Package security-misc from Whonix to Qubes" only as "make security-misc usable in the Qubes Debian templates too". The genmkfile auto generation (and then commit to git) of the Fedora packaging files part however looks doable which I could commit in the near / mid future.

but may require extra steps over automated `genmkfile`.

FWIW, supports hooks, even drop-in folders for customization.

> Creating the `version` file could be automated. genmkfile already > has `make make deb-chl-bumpup-major` and a new feature of adding > upstream version number into `version` file would be easy for me. FWIW, we do that the other way around: [generate debian changelog](https://github.com/QubesOS/qubes-builder-debian/blob/master/scripts/debian-changelog.sh) from `version` file and git changelog.

debian/changelog is also generated by manual run of genmkfile, and then committed to git. In effect, many package should be Debian policy conform and ready to be uploaded to packages.debian.org. Auto generation of debian/changelog would prevent the package from ever entering packages.debian.org.

> Now the complicated part is `rpm_spec/genmkfile.spec.in`. What I > really don't like is keeping track of all file names (`%files`) > manually. In theory it's possible to list everything with wildcard (`/*` or such), but it is considered bad practice.

Would (`/*` or such) still be better than not implementation or auto generating (and then committing to git) all files?

> That's one of the main reasons why genmkfile was invented. I am > wondering if genmkfile could auto generate > rpm_spec/genmkfile.spec.in? Might be a good idea. Indeed I've copy&pasted significant part of it from `debian/control`. But the file should be committed to the repository.

Committing to repository was what I had in mind. Important to have these files ready for public review and patches. Having the help of a script creating these files however would help making multiple of Whonix's Debian packages by Whonix available in Qubes Debian based templates.

[marmarek]

debian/changelog is also generated by manual run of genmkfile, and then committed to git

Yes, this is exactly what we do too. Simply the generator is different.

Would (/* or such) still be better than not implementation or auto generating (and then committing to git) all files?

The idea of %files is to ease spotting unexpected/missing files while packaging. For example missing dependency may result in not building some module. Not very relevant for cp -r type of package.
Is genmkfile used once for package initialization, or do you re-run it from time to time (for example to synchronize README with debian/control)?
If you run it only once, I'd go with wildcards. Less work.

[adrelanos]

Marek Marczykowski-Górecki:

> Would (`/*` or such) still be better than not implementation or auto generating (and then committing to git) all files? Not very relevant for `cp -r` type of package.

Alright.

Is `genmkfile` used once for package initialization, or do you re-run it from time to time (for example to synchronize `README` with `debian/control`)?

New packages are created manually. (By copying over an existing package structure and then changing all of the files accordingly using mass search and replace, manual verification.) debian/control to README is done by script https://github.com/Whonix/whonix-developer-meta-files/blob/master/debug-steps/packaging-helper-script function pkg_readme_creator which gets manually run from time to time (very low priority). packaging-helper-script has also a function pkg_need_version_bump_and_pkg_build_and_reprepro_add which: - verifies we are using a signed commit (sanity test only, not security, since all is manually verified on my local machine before singing) - bumps debian/changelog - refreshes changelog.upstream (which is just a git log dump) - creates a signed git tag with the new version number - builds the package (lintian --pedantic; inside cowbuilder chroot) - adds the package to local repository - which I'll then upload to deb.whonix.org developers repository - which I'll then then - when then flows to other repository suites "builds the package" means "make deb-pkg" which runs a few genmkfile steps - make dist - make debdist - make debdsc - make deb-pkg-build make deb-pkg-build uses cowbuilder (... or debuild ...) which internally uses standard Debian build tools which internally uses "make install" but with environment variable DESTDIR set to suit packaging. "make install" in essence (shortened for simplicity) does: make_folder_list_for_un_and_install="bin boot dev etc home lib opt sbin srv sys usr var" for d in $make_folder_list_for_un_and_install; do cp -R "$d" "$DESTDIR" I am using "make install" quite often manually during development just because it is faster than full package reinstall (which of course requires knowing the differences between "make install" and a full package such as maintainer scripts). A standard "make install" is also implemented to have a compliant, complete makefile to ease porting for anyone who wishes to fork. So if you want so, there is no auto generated packaging file which describes which file gets copied where similar to %files. From genmkfile readme:

Files in etc/... in root source folder will be installed to /etc/...,

files in usr/... will be installed to /usr/... and so forth. This should make renaming, moving files around, packaging, etc. very simple. Packaging of most packages can look very similar. Renamed/removed/new files are mostly really out of my mind since this is fully automated, abstracted away. genmkfile kinda results in `/*`.

If you run it only once, I'd go with wildcards. Less work.

Basically the wildcards (actually just bin boot dev etc home lib opt sbin srv sys usr var) are run on every build without having to think about it. But indeed, if Fedora needs different paths (or maintainer scripts), then things get more complicated.

[adrelanos]

The auto generation of rpm spec files can be considered future work.

Are these manually created rpm spec files good enough to continue with Qubes interrelation of this very security-misc package?

[marmarek]

Are these manually created rpm spec files good enough to continue with Qubes interrelation of this very security-misc package?

Yes.
Now it requires testing, especially interaction with qubes packages. On Debian it's somehow already covered in Whonix. But not in Fedora. I'm traveling this and the next week, so I have limited options.

If that's major problem for now, I could start with uploading to Debian repository first and upload to Fedora later.

[adrelanos]

Removes read, write and execute access for others for all users who have home folders under folder /home by running for example "chmod o-rwx /home/user" during package installation, upgrade or pam. This will be done only once per folder in folder /home so users who wish to relax file permissions are free to do so. This is to protect previously created files in user home folder which were previously created with lax file permissions prior installation of this package.

This could use security review.

File https://github.com/Whonix/security-misc/blob/master/usr/share/pam-configs/permission-lockdown-security-misc effective results in files /etc/pam.d/common-session / /etc/pam.d/common-session-noninteractive adding after:

session required pam_unix.so

A new following line:

session optional pam_exec.so debug seteuid /usr/lib/security-misc/permission-lockdown

Actual implementation is here:
https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/permission-lockdown

Security discussion: I had in mind if using malicious user names in /home leading to root code execution by users, but this isn't possible because to create a malicious user name, root access is required in the first place. And one who has root access, does not bother exploiting /usr/lib/security-misc/permission-lockdown. Also pam sets sane environment variables which are not in reach by non-root users at that stage. Not using set -e or so because this script failing shouldn't block login.

See also:
https://manpages.debian.org/buster/libpam-modules/pam_exec.8.en.html

Unfortunately adduser does not support hooks yet.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=36019
Therefore using pam_exec to make sure home folder gets right permissions before user login.
Postinst isn't a reliable way to enable this either since the installation time of the security-misc package isn't fixed during build of VM images. User "user" may or may not be created by the time of the installation of the security-misc package.

[DemiMarie]

I think module signing and kernel lockdown are very important parts. u2mfn.ko does not present an obstacle, as it and wireguard.ko can be built along with the kernel. This does imply that users will not be able to install their own kernel modules into a dom0-provided kernel, but users can always use distro-provided kernels where that is needed.

[adrelanos]

discussion allow loading signed kernel modules by default / disallow kernel module loading by default:
https://forums.whonix.org/t/allow-loading-signed-kernel-modules-by-default-disallow-kernel-module-loading-by-default/7880

allow loading signed kernel modules by default was implemented:
https://github.com/Whonix/security-misc/blob/master/etc/default/grub.d/40_only_allow_signed_modules.cfg

disallow kernel module loading by default was reported to cause issues, needs research and development.

---

This has lead to a related discussion.
Untrusted Root - does it make sense to try to improve security by restricting root?
https://forums.whonix.org/t/untrusted-root-does-it-make-sense-to-try-to-improve-security-by-restricting-root/7998

---

Indeed no restrictions of user freedom.

As far as I know, any /etc/sysctl.d drop-in or /etc/default/grub.d boot parameter drop-in can be disabled by:

• deleting that configuration file (this will always work)
• dropping a lexical higher configuration file snippet that will undo the previous configuration file snippet (this will work likely, should work, but needs testing)

[adrelanos]

Could you please review the new remount-secure feature.

remount /home, /tmp, /dev/shm and /run with nosuid,nodev (default) and noexec (opt-in). To disable this, run sudo touch /etc/remount-disable. To opt-in noexec, run sudo touch /etc/noexec and reboot (easiest).

• Kicksecure/security-misc@470cad6
• https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/remount-secure
• https://github.com/Whonix/security-misc/blob/master/lib/systemd/system/remount-secure.service

Specifically important is that the systemd unit file won't cause any systemd dependency cycles or break Qubes (home) folder mounting.

[arno01]

template-buster failed because of the security-misc package while building Qubes OS R4.1.
The package's preinst script expects a at least a single user to be in a sudo group so there is a way for switching to a root user.

(building in fc29 templatevm)
/home/user/qubes-builder/build-logs/template-buster.log
...
...
#####################################################################
## INFO: BEGIN: security-misc preinst install
#####################################################################
'
+ '[' install = install ']'
++ getent group sudo
++ cut -d: -f4
+ sudo_users=
+ OLD_IFS='     
'
+ IFS=,
+ export IFS
+ IFS='         
'
+ export IFS
+ '[' '!' '' = yes ']'
+ echo '/var/lib/dpkg/tmp.ci/preinst: ERROR: No user is a member of group '\''sudo'\''. Installation aborted.'
/var/lib/dpkg/tmp.ci/preinst: ERROR: No user is a member of group 'sudo'. Installation aborted.
+ exit 200
dpkg: error processing archive /tmp/apt-dpkg-install-kxDcGx/109-security-misc_3%3a9.11-1_all.deb (--unpack):
 new security-misc package pre-installation script subprocess returned error exit status 200
...
...
Unpacking qubes-whonix-gateway (3:14.7-1) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-kxDcGx/109-security-misc_3%3a9.11-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Removing 'local diversion of /sbin/initctl to /sbin/initctl.distrib'
make[1]: *** [Makefile:64: rootimg-build] Error 100

[marmarek]

I vaguely remember it was fixed already, maybe outdated version?

[adrelanos]

Yes. Fixed in git master, developers and testers repository.

[arno01]

Found it Kicksecure/security-misc@660837d

As the latest stable build breaks with the security-misc <14.5-1 will this fix get to the previous version of security-misc package, e.g. 9.11-1 that gets into Qubes R4.0?

As a workaround, I am adding $chroot_cmd usermod -a -G sudo user line right before this block https://github.com/Whonix/qubes-template-whonix/blob/eb2fe62afe0dc2f3614d823129ebd53806f3c6c1/whonix-gateway/04_install_qubes_post.sh#L97-L102

[adrelanos]

The fixed package will migrate to all repositories as per usual. It's a slow process since the tool chain is underdeveloped. This issue wouldn't happen in the first place if there was proper automated testing. Help welcome. Some starters: https://forums.whonix.org/t/looking-for-contributor-automated-test-suite/5942 https://phabricator.whonix.org/T709

[marmarek]

Responded in the thread about automated tests. Should I include some other repo in openqa tests too? I don't think I've seen security-misc installation failure on an update in any of the test runs. Or maybe the problem applies only to the fresh template build, not update?

[adrelanos]

Marek Marczykowski-Górecki:

Responded in the thread about automated tests.

Me too.

Or maybe the problem applies only to the fresh template build, not update?

Possible. Best to have test cases for both.

[DemiMarie]

Not sure, but contributions would be appreciated.

[andrewdavidwong]

@bluesteal: Please note that the issue tracker (qubes-issues) is not intended to be a place for fielding questions. Instead, we have other venues meant for asking questions, asking for help, and having discussions. (By contrast, the issue tracker is more of a technical tool intended to support our developers in their work.) Thank you for your understanding!

[SvenSemmler]

Unfortunately @andrewdavidwong has to repeat the same thing over and over. It's not a big deal if someone who has just learned of this project is ignorant of the guidelines and posts something here that doesn't belong into the issue tracker. Andrew will point to the guidelines, no harm done. The real question is: how many reminders do you @bluesteal need before being constructive?