Splitting security-misc into shared, desktop, and server packages

Development
1

Read through the discussion at Split the `security-misc` into `security-misc-shared`, `security-misc-desktop` and `security-misc-server` · Issue #187 · Kicksecure/security-misc · GitHub, and created a table of (almost) all of the files and directories in security-misc, along with what subpackage they should go into. The vast majority of the package looks like it can remain shared. Some bugs were also potentially uncovered while reviewing this.

The full table is very large and has very long lines, so rather than pasting it here, I put it in a GitHub gist here: Suggested way to split the security-misc package into shared, desktop, and server packages. · GitHub

1 Like
2

I’d like to address the bugs found first, as that seems easy and to simplify this discussion.

  • [!] │ │ ├── pkexec.security-misc (shared) (useful on desktop and server, however lxqt-sudo won’t be present on a server, but pkexec may be used on a server. Resolve by allowing the use of sudo.)

Fixed by deleting this legacy leftover file.

  • [!] │ │ ├── disable-kernel-module-loading (shared) (useful on desktop and server, BUT SOMEHOW ISN’T SET EXECUTABLE???)

Fixed.

* [!] │   ├── dkms                                                                                  (none)    (see files below)
* [!] │   │   └── framework.conf.d                                                                  (none)    (see files below)
* [!] │   │       └── 30_security-misc.conf                                                         (none)    (should be moved out of security-isc)
  • [!] │ │ │ ├── panic-on-oops.service (shared) (useful on desktop and server, systemd config looks invalid with a conflict between WantedBy and After)

Fixed.

* [x] │ │ ├── install matroxfb_bases /usr/bin/disabled-framebuffer-by-security-misc (shared) (ancient, obsolete, TYPO'D - THIS SHOULD BE BASE, NOT BASES)

Fixed.

All bugs should have been addressed.

Server? Could also be a home server with a GUI?

  • │ │ ├── glib-compile-schemas /usr/share/glib-2.0/schemas || true (desktop) (glib-compile-schemas is of no use on a server)

No use but also no harm? So just keep as is for simplicity? Also a remote server might have a GUI.

  • │ ├── security-misc.gconf-defaults (desktop) (nautilus won’t be present on a server)

Similar as above. Doesn’t harm and useful if a GUI is used on the server.

* [x] │ ├── bluetooth (desktop) (all subfiles are desktop)
* [x] │ │ └── 30_security-misc.conf (desktop) (bluez should only be present on desktops)

But if on a server, this config does not harm, even useful?

* [x] │ │ ├── 25_default_whitelist_hardened_malloc.conf (server) (desktops don't use hardened-malloc)

We actually did but Hardened Malloc is nowadays deprecated in Kicksecure.

* [x] │ │ ├── 25_default_whitelist_postfix.conf (server) (desktops shouldn't run postfix)

The primary defense for desktops would be not installing postfix then? But then postfix might be installed thorugh a Depends:, or Recommends:. In that case, indeed, best if not whitelisted.

* [x] │ │ ├── 25_default_whitelist_spice.conf (desktop) (only desktops need USB passthrough with SPICE)

SPICE over network to server?

I guess I would tend to keep as much shared as possible. The more remains shared, the less migration work there will be.

The file per file analysis is a great approach!

3

It turns out I was wrong here - the config looked invalid but actually was not. I had mistakenly thought that WantedBy required the wanted service to start before the wanting service. This was false, the systemd.unit manpage states:

Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If unit foo.service pulls in unit bar.service as configured with Wants= and no ordering is configured with After= or Before= , then both units will be started simultaneously and without any delay between them if foo.service is activated.

So having a unit be both WantedBy=multi-user.target and After=multi-user.target is actually valid. Furthermore, removing the After=multi-user.target line has resulted in an error message on boot:

[ SKIP ] Ordering cycle found, skipping panic-on-oops.service

Adding back After=multi-user.target to /usr/lib/systemd/system/panic-on-oops.service resolves the issue.

Sorry about the mix-up here.

1 Like
4

No worries.

Fixed by git revert.

5

Hmm, I see a lot of your points here. I think the only one I disagree with is the SPICE whitelist point - the spice-client-glib-usb-acl-helper being granted an exception from permission-hardener here is apparently only used when a host is passing through USB devices to a guest. (See Debian -- Details of package spice-client-glib-usb-acl-helper in sid) I don’t foresee this happening frequently (if ever) on a server. In theory, an attacker could use USB passthrough to compromise a confidential VM should they gain access to the host (use USB-over-IP to connect a malicious USB device to a compromised server remotely, then pass it through to the target VM and exploit a driver within the VM to gain a foothold there). Finally. the binary is setuid. Obscure-but-insecure things are where a lot of vulnerabilities are found, like the recent CUPS RCE.

1 Like
6

I no longer know how important that exception for spice-client-glib-usb-acl-helper is at all. Cannot find how it ended up getting added.

spice-client-glib-usb-acl-helper isn’t installed by default in Kicksecure (or Whonix). Not even inside VMs.

Therefore, someone who installs it, will actually need it.

The issue is also that the threat model of permission hardener isn’t well enough defined.

spice-client-glib-usb-acl-helper isn’t installed by default and doesn’t install itself using apt install spice-client-glib-usb-acl-helper by accident either. If malware was able to run apt install spice-client-glib-usb-acl-helper, then there would already be a root compromise and permission hardener couldn’t help anymore either.

From that perspective, that exception can stay shared for simplicity?

Right.

That’s why permission hardener disables many historically used SUIDs that are nowadays no longer popular (at least not by Kicksecure (or Whonix) users).

Some examples include:

These are well suitable for permission hardener, since these are installed by default and hard (infeasible? / impossible?) to not have installed by default.

This is the main motivation for permission hardener. To disable SUIDs where it’s not strictly required for most users, yet having these binaries around is “mandatory”.

However, for packages such as spice-client-glib-usb-acl-helper maybe, the SUID functionality might be specifically wanted by the user?

7

Not necessarily:

[user ~]% apt-cache rdepends spice-client-glib-usb-acl-helper
spice-client-glib-usb-acl-helper
Reverse Depends:
  libspice-client-glib-2.0-8
[user ~]% apt-cache rdepends libspice-client-glib-2.0-8
libspice-client-glib-2.0-8
Reverse Depends:
  virt-viewer
  spice-client-glib-usb-acl-helper
  vinagre
  spice-client-gtk
  gir1.2-spiceclientglib-2.0
  libspice-client-gtk-3.0-5
  libspice-client-glib-2.0-dev
  gnome-boxes

So in theory, a user who wants to run VMs on the server might end up installing virt-viewer, gnome-boxes, or similar, and end up pulling in the SPICE client library, which then in turn pulls in this obscure SUID executable for dealing with one portion of USB passthrough. For users who actually need USB passthrough, this is fine, but for other users, it could potentially be an issue.

This is really hypothetical though. Why would someone install gnome-boxes (a desktop application) on a server? If they want to run VMs on a server, they’d install libvirt on it, and then connect to libvirt using software like virt-manager from a client machine. So meh. I personally would rather leave it out of the exceptions for servers, but it’s not something I’m set on. If you’re happier with it shared, I’m fine with that.

1 Like
8

Great resoning!

Alright, let’s do it.

1 Like