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

[monsieuremre]

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.

[adrelanos]

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...)

[monsieuremre]

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

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

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

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. You can use your desktop workstation with no GUI. But you can still apply the privacy extensions and mac randomization and the network hardening. The classification here is server and workstation.

We should make the following assumption only:
Server: CLI
Workstation: GUI or CLI

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.

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

[adrelanos]

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.

[monsieuremre]

Firewall very most likely needs a dedicated package
True.
and there's quiet a lot technologies to choose from.
Also true.
I guess netfilter-persistent + nftables might be most suitable, configurable.
I think so too. So we won't configure a firewall daemon. We will be the firewall directly as the package I guess.
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. And its main and quasi only purpose is preventing clear net leaks. So even if ported, it would change almost completely.

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.

Having a shared package is an absolute must have to avoid code duplication
I see. This can be done.

You could contribute to security-misc-desktop only.
Don't get me wrong, I am against the idea of supporting servers, but if there is a package, I would still try to contribute.

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.

[adrelanos]

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.

[monsieuremre]

Ok I think splititng the package is a no brainer and is easy to implement. But handling the building of these three packages within the same repository will be the optimal way to do things. I do not understand why you are trying to avoid makefiles at all costs. I can easily write a makefile for this task and it would work very well. I don't know much about genmkfile, so I'm not sure how that would be implemented. I will create pull with the different config files that are meant for desktop or server specifically, it will be incomplete, but work can be tracked better that way I think.

[monsieuremre]

A broad list of what and how I think stuff should be split between packages:

Should be moved or added to the desktop version:

• Thunderbird any desktop application hardening.
• Mac addres randomization.
• Privacy extensions in kernel and network hardening, including disabling routing and stuff.
• SGID binaries having exceptions (no exceptions on server).
• Different hardened mount options.
• Bluetooth hardening, module still active.
• Remote login, remote root, remote anything, all disabled.

Should be moved or added to the server version:

• Disabling bluetooth, usb, and a lot of other kernel modules directly.
• No mac randomization.
• No sgid exceptions.
• No hardened malloc exceptions.
• Hardened mount options, including hiding proc.
• No hiding hardware info stuff, non-reasonable on servers.

Anything else should be shared.

[adrelanos]

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?

[adrelanos]

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.

[monsieuremre]

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.

I see your point. Good approach to make sure the project does not die randomly, given its small size. I do not know what other ways there are to achieve this. But I think this could be improved upon, since it might make development harder at the same time whilst easing maintenance. I am not educated in the subject, so I might be wrong.

[raja-grewal]

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?

[adrelanos]

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.)

[monsieuremre]

This issue is problematic. The supposed server support of this package is not real. Only a subset of server types are supported inherently due to network hardneing in the kernel. Routing won't work for example. But if we say yes most servers, then we can split the package. But really, I think before that, the unnecessary complexity of package content (with no benefit) should be addressed to facilitate the process.

[adrelanos]

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

[monsieuremre]

I am into this. Actually I am more into the firewall thing, because it does not exist yet, so it is much easier to do. Splitting and gutting this package is however very undoable. Also good insight, no firewall for server, server admins should do that themselves. actually server also should do hardening themselves too. Server support is not a good idea for anything.

For a desktop tho, it is not really difficult to write a universal desktop firewall config that won't break anything at all. We should not depend on ufw or firewalld, those are too high level, unnecessary. We are the OS, so we gotta use nftables configs. It should be trivial to write one. For example:

table inet filter {

    # Incoming connections
    chain input {
        # Deny all incoming connections by default
        type filter hook input priority 0; policy drop;

        # Allow connections from localhost
        # Local network sharing and stuff, you name it
        iif lo accept

        # Allow incoming connections for CUPS
        # Local printer scanning, I guess? Might not be necessary actually, because outgoing is allowed.
        tcp dport 631 accept
        udp dport 631 accept

        # Allow peer to peer torrenting
        # If you are a charitable seeder of Linux ISO's or something
        tcp dport 6881-6889 accept

        # Allow Avahi
        # Is this necessary, I don't know
        # Probably not, because we establish avahi connections, I am guessing
        udp dport 5353 accept
    }
    
    # Outgoing connections
    chain output {
            type filter hook output priority 0;
            
            # Allow outgoing that we establish
            ct state established,related accept
        
            # Drop invalid state
            ct state invalid drop
    
            # Block outgoing ports for known unencrypted network protocols
            # imap, pop, telnet, ftp, snmp, smtp, tftp, ntp
            # Encrypted versions of these like imaps, pop3s etc are still allowed
            # Literally any mail provider etc. will support the encrypted versions of these protocols
            # If yours doesn't, it might be time to move past 2005
            tcp dport { 143, 110, 23, 21, 161, 25, 69, 123 } drop
            udp dport { 143, 110, 23, 21, 161, 25, 69, 123 } drop

            counter drop
    }

    # Forwarding
    chain forward {
            # Just don't allow any forwarding ever
            type filter hook forward priority 0; policy drop;
            
            # Wanna count what's dropped? I don't know
            counter drop
    }
}

A config like this can't break anything anywhere on 99% of desktops. Just an example, a proof of concept.

Anyway, as I said, this package needs a fresh start or something to be separated properly. Unnecessarily complex and entangled inner structure. Needs a clean-up.

[monsieuremre]

First steps needed:

• Abolish all the scripts in the package. Whenever we need to execute something, conditionally or not, stick to systemd services only. For maintainability.
• Remove the unused bloat from everywhere, or move them to a dedicated development branch, like non-enabled features and rpm things etc.
• Reduce implementation complexity. Literally difficult to maintain.

But also not that I don't support keeping the server support. A non-worth use of energy and resources if you ask me. Server admins should do their hardening themselves. Because depending on the function of the server, the way we harden will be absolutely different. The current hardening for example will break a server that needs to support packet forwarding. Which is valid and not that rare. So we already do not have server compatibility anyway, and we kinda can't in a real sense, because servers are really different from each other inherently. You can use them for different purposes. Anyway, just a side note.

[adrelanos]

Firewall needs to be discussed elsewhere. Off-topic here.

[adrelanos]

We don't necessarily need to implement security-misc-server. That could be skipped and done much later or never.

But should split into:

• security-misc-shared
• security-misc-desktop

Abolish all the scripts in the package. Whenever we need to execute something, conditionally or not, stick to systemd services only.

I don't see how permission hardener can be converted into a systemd unit. Systemd units running scripts is a good design.

[ArrayBolt3]

I think it's worth noting that what is worthwhile on a server vs. what is worthwhile on a desktop is somewhat a matter of opinion. Looking at some of the discussion here, for instance:

Only applicable to servers: Hiding /proc with no exceptions

Why? What about a workstation where multiple users are logged in at the same time and use a user switching feature to manage multiple simultaneous logins? Should everyone with physical access to the machine be able to snoop around in what the other users are doing?

Only applicable to servers: Disable usb module

I think this is a bad idea in general. There are plenty of reasons someone might plug a USB drive into a server, especially if the server is a tower rather than a rackmounted device. I can see the argument to be made here, but this seems like it could be asking for trouble.

Only applicable to servers: Disable a lot of modules, literally every physical or possible

As I understand it, Debian (or more properly udev) automatically detects the modules it needs and loads them on an as-needed basis. Disabling a module disables a hardware feature, and that's not something that a distro developer should do unless a specific piece of hardware is known to be trouble. The system administrator is the only one who can know what hardware they do and don't need, and they can configure blacklisting themselves.

I think I agree with the other comments, but more discussion probably needs to be done on some of these points. I'm currently compiling a list of what I believe should be moved to desktop, what I think should be moved to server, and what should remain shared.

[ArrayBolt3]

Alright, I've gone through and looked at every file in security-misc, categorizing them into shared, desktop, and server categories as best I can. The full audit is at https://gist.github.com/ArrayBolt3/1fef29b2214f27054cd85785530e7f7f, and a forum discussion is available at https://forums.kicksecure.com/t/splitting-security-misc-into-shared-desktop-and-server-packages/674.

[adrelanos]

I think it's worth noting that what is worthwhile on a server vs. what is worthwhile on a desktop is somewhat a matter of opinion. Looking at some of the discussion here, for instance:

Only applicable to servers: Hiding /proc with no exceptions

Why? What about a workstation where multiple users are logged in at the same time and use a user switching feature to manage multiple simultaneous logins? Should everyone with physical access to the machine be able to snoop around in what the other users are doing?

This might be more an issue of feasibility. Not sure it is feasible on the desktop. There are quite some issues:

https://github.com/Kicksecure/security-misc/issues?q=is%3Aissue+is%3Aopen+%2Fproc+in%3Atitle

Otherwise, sure, hiding /proc would be awesome.