Split the security-misc into security-misc-shared, security-misc-desktop and security-misc-server

Servers and workstations differ heavily, and there is no universal hardening that is also fine grained for both. A server is inherently a network. This package should prioritize workstations, as kicksecure is meant to be one. I do not support the idea of also being a server system. Firstly, some of hardening already eliminates the possibilty of kicksecure usage on specific server types, like a file sync or an email server might already face problems because of network hardening. They may have gone unnoticed, but this doesn't change the fact. The two reasonable options are:

Primarily good option: Forget about servers, do not try to keep support for them universally. This strips us of a very very big area of possible hardening options. If we want to support both, in terms of security, we will be the "jack of all trades, master of none". Nothing would be hardened to its full extend in this case.
Secondary, in my opinion the least favorable option, because of the unnecessary work it would require: Split this package in two. One package security-misc-desktop and one security-misc-server. At this point you can choose any other name you like.

But this has to be addressed in the near future, for the project to develop further.

Servers and workstations differ heavily, and there is no universal hardening that is also fine grained for both. A server is inherently a network.

Ok.

This package should prioritize workstations, as kicksecure is meant to be one.

Not really. I always developed everything in universal ways to not loose any functionality that can be used if using Debian. This is going to stay this way.

Firstly, some of hardening already eliminates the possibilty of kicksecure usage on specific server types, like a file sync or an email server might already face problems because of network hardening.

Both Kicksecure, and Whonix have e-mail server and rsync server functionality. So far no issues because of any hardening.

They may have gone unnoticed, but this doesn't change the fact.

You mean in theory, a project with supposedly exponentially more traffic (such as protonmail while not on the level as gmail for sure having much more e-mail traffic). If such a project was to consider Kicksecure, I would assume they have engineers who figure that stuff out. It's not really something I can avoid breaking because I don't administrate such high traffic systems.

One package security-misc-desktop and one security-misc-server.

The names are good just another consideration...

Do you see CLI configs which aren't applicable to -server? Example? If any CLI configs, could these be added to -desktop?

Also I'd keep the current security-misc as a shared package compatible with both desktop and server. But the additional packages can be created after above question was settled. Things which apply to both do not need to be duplicated. Avoiding code (or config) duplication.

In summary, at least 3 packages:

security-misc (shared) (maybe one day renamed to security-misc-shared)
security-misc-desktop
security-misc-server

I hope not more packages. (There's a similar issue with packages vm-config-dist or usability-misc - is it for desktop or server...)

Let me give some examples first.

Only applicable to workstations:

IPv6 privacy extensions.

Mac address hardening.

Super hardened firewall configurations (hopefully coming soon as I suggested in another issue)

Block remote login

Block remote everything really

Probably some more stuff

Good.

Super hardened firewall configurations (hopefully coming soon as I suggested in another issue)

Firewall very most likely needs a dedicated package and there's quiet a lot technologies to choose from. I guess netfilter-persistent + nftables might be most suitable, configurable. Dunno about UFW and complex security settings. Or porting whonix-firewall which has some general security features to Kicksecure.

Only applicable to servers:

Hiding /proc with no exceptions

Disable bluetooth module

Disable usb module

Disable a lot of modules, literally every physical or possible

Default hardened malloc the original on anything and everything

And probably more

Probably also good.

As you see, keeping compatible for both ends stifles us.

What's currently in security-misc - which is a lot - seems very compatible with both.

Some configs, systemd units suitable by default for a server might still be suitable on an opt-in / per VM basis for desktops.

Do you see CLI configs which aren't applicable to -server? Example? If any CLI configs, could these be added to -desktop?

CLI is a term we should not use.

That's... Well... For the future.... Because kicksecure-meta-packages (and whonix-meta-packages) uses this term a lot and difficult to migrate away from it.

Happy to avoid the term CLI for security-misc.

I do prefer the word "desktop" over "workstation" just because "workstation" in Whonix "workstation" does not mean "desktop" but just the "the place where most applications / servers run".

I think the differences are significant enough to warrant a complete split of the package. Having extra additions and having one universal package is more complicated in my opinion. But if you think this is easier to manage and maintain, then go with that.

Having a shared package is an absolute must have to avoid code duplication (or config duplication). This is also how Debian (and probably most other distributions) handle packaging. No code duplication. And I agree with this. For the few places where code was duplicated in Kicksecure it has always been a hassle to not only update one but both.

But once again, I personally think server compatibility is a distraction here, and is better dropped.

You could contribute to security-misc-desktop only. Only security-misc-server might take a long time to materialize.

Or porting whonix-firewall
I might be wrong but the whonix firewall is very unsuited for any system, desktop or server, it is not applicable. It is suited for a virtual machine that is separate.

Not tied to virtual machines. Also suitable for Whonix with physical isolation.

And its main and quasi only purpose is preventing clear net leaks.

That feature needs to be removed when ported that's for sure.

So even if ported, it would change almost completely.

Right but many parts don't need to be re-invented. Examples:

the loading mechanism
config parsing (obviously change the folder name)
error handling
functional nft_drop_invalid_incoming_packages
packaging (just string replace whonix -> kicksecure)

That's how I would probably do it. Obviously, it would not have any anonymity features anymore. Only security features.

What's currently in security-misc - which is a lot - seems very compatible with both.
I would disagree. A serious server would better need a lot of modules disabled for good for better attack surface reduction. Our hardening is good for desktop usage.

For example the grub config based Linux kernel parameter hardening can remain shared for the most part. (Not sure what needs to be different.)

How about having two separate packages, but only one repository. This is common practice for a lot of projects. There is no make file per se but, it is like having too make targets in the Makefile.
make desktop
make server
I can create a make file. Make dependencies can also be installed this way easily. I am not sure if this would be conventional or common place in debian packages. Calling dpkg-buildpackage in the makefile I mean. If it is something that is conventionally a ok, I think this would be the better choice.

All in 1 repository, this repository but with sub folders (shared, desktop, server) seems actually better indeed.

But some implementation details...

Needs to be genmkfile style. Meaning: no manifest file maintained by hand. I.e. not declaring each and every file etc/default/grub.d/40_cpu_mitigations.cfg copy to /etc/default/grub.d/40_cpu_mitigations.cfg.

Similar to the already existing debian/security-misc.install. Might not even need a makefile. Something like this:

debian/security-misc-desktop.install

desktop/etc/*

Make files are to be avoided. Maybe a make file that runs a bash script if really needed but I hope not.

genmkfile also has all the usual targets, so things such as sudo genmkfile install already work fine. Improving genmkfile to use sub folders such as shared, desktop, server would be nice too.

I might implement this in the mid future. Faster if contributed.

Feel free to start adding stuff to desktop / server sub folders. The more stuff is there the more obligated I'll feel to implement this.

Mostly good.

SGID binaries having exceptions (no exceptions on server).

Some exceptions needed.

servers need sudo
hardned malloc shared object requires SUID so it can be applies for SUID applications. References:
- https://forums.whonix.org/t/hardened-malloc-hardened-memory-allocator/7474/224
- https://web.archive.org/web/20231223101913/https://gist.github.com/SkewedZeppelin/7f293d64c1c651bdc21526519d9e192b

Different hardened mount options.

Useful for both, desktop and server.

No hardened malloc exceptions.

What do you mean by hardened malloc exceptions?

No hiding hardware info stuff, non-reasonable on servers.

How come?

But handling the building of these three packages within the same repository will be the optimal way to do things.

Ok.

I do not understand why you are trying to avoid makefiles at all costs.

You can see it as an implicit (meaning not previously spelled out) Kicksecure policy that all packages maintained by Kicksecure, that were invented by Kicksecure (meaning no such packaging existed before) need to be simple, generic, genmkfile based, no make files, no manifests. If I add a repository that isn't compatible with genmkfile it creates a mess for the build system and my development, build processes.

Packages need to be easily maintainable, potentially few regressions, robust, simple, you name it.

Because at time of writing, I am maintaining 2 Linux distributions, Kicksecure (56 repositories), Whonix (16 repositories), for various platforms (bare metal, Qubes, Virtualbox) + documentation + server + user support + bureaucracy.

So I need to be extra strict to have high quality implementations that may initially take a longer time but are therefore low maintenance in the future.

This is overall good idea.

This link is broken for me:

  * https://gist.github.com/SkewedZeppelin/7f293d64c1c651bdc21526519d9e192b

Should there be changes to hardened_malloc settings for the desktop/workstation variant compared to what currently exists?

https://web.archive.org/web/20231223101913/https://gist.github.com/SkewedZeppelin/7f293d64c1c651bdc21526519d9e192b

Should there be changes to hardened_malloc settings for the desktop/workstation variant compared to what currently exists?

I hope not. On the server hardened malloc is easier to use. (Most likely no VirtualBox, no GUI browsers that can break.)

https://forums.kicksecure.com/t/meta-packages-kicksecure-desktop-versus-kicksecure-server/415

@ArrayBolt3

Our plan is to rename all files in this repository as follows. For example,

/etc/default/grub.d/40_cpu_mitigations.cfg will be renamed to /etc/default/grub.d/40_cpu_mitigations.cfg#security-misc-shared.

The hash ("#") character will be used as a separator. What comes after the separator will be the name of the package in which the file will be placed.

This will allow us to split the security-misc into security-misc-shared, security-misc-desktop and security-misc-server while keeping security-misc contained inside a single source code (GitHub) repository.

This will happen before Kicksecure 18 (Debian trixie based) will be released which is next on the roadmap.

(As discussed privately with @ArrayBolt3.)

Split the `security-misc` into `security-misc-shared`, `security-misc…

packaging split

packaging

make install files executable

adjust lintian overrides file

rename

packaging

security-misc-server placeholder

`Replaces: security-misc`

`security-misc` -> `security-misc-shared` package migration

This has been implemented.

Navigation Menu

Repository navigation

Split the `security-misc` into `security-misc-shared`, `security-misc-desktop` and `security-misc-server` #187

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Split the security-misc into security-misc-shared, security-misc-desktop and security-misc-server #187

Description

Activity

adrelanos commented on Jan 14, 2024

adrelanos commented on Jan 15, 2024

adrelanos commented on Jan 15, 2024

adrelanos commented on Jan 17, 2024

adrelanos commented on Jan 17, 2024

raja-grewal commented on Jan 24, 2024

adrelanos commented on Jan 24, 2024

adrelanos commented on Mar 18, 2024

7 remaining items

adrelanos commented on Sep 16, 2025

adrelanos commented on Oct 19, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Split the `security-misc` into `security-misc-shared`, `security-misc-desktop` and `security-misc-server` #187