feat: hardening configs #43

boredsquirrel commented 2025年01月23日 17:53:49 +01:00

#32

I went through the secureblue configs, selected the ones I use myself, changed some minor things.

These changes include

• storing scripts in one place, /usr/local/bin (allowing root users to delete or change them)
• using /usr/bin/run0 in some of them, some still need to be invoked as root I guess
• adding some scripts
• separating files like modprobe.d hardening, to make "softening" easier

The additions:

• add a secureblue license note and attach the Apache 2.0 license text
• chronyd config from GrapheneOS
• add a few distrobox container configs that use cosign signatures for verification
• configure distrobox
  • create a separate directory per box, $HOME/distrobox/boxname
  • use the latest Fedora container image by default (needs no maintenance)
• modprobe.d
  • block various commonly unused kernel drivers from loading
  • separate bluetooth blocking file to make it easy to comment it out to allow it
  • same for some filesystems that some people might use
  • additional file to override allow modules if people want that
• public cosign keys for various containers to have the root of trust in this OS
• SDDM config to use wayland, basic rendering and remove some advanced features for hardening
• disable coredump as it allows apps to gain detailed info about the OS
  • 3 config files, one parameter, see the scripts
• not enforced password quality checks
• enforce SELinux confinement for chrony (as fas as I understood) and improve behavior when having been killed as it did something bad
• various sysctl hardening parameters
• systemd resolved: use encrypted DNS opportunistically. This should keep captive portals working, and is vulnerable to downgrade attacks, but probably most usable. Adding a disabled file for real security hardening (with a few set encrypted DNS providers) could be useful
• udev: add rules for Google titan and various other HOTP keys for 2FA, including Nitrokey, Solokey, Yubikey
• disabled: disable KDE extension support as they are a vector for unchecked executable code (see issues like this one)
• dracut: enable tpm and fido2 for LUKS unlocking
• scripts
  • enable and disable the cups systemd service. Provides easy hardening which can easily be turned off. Alternatively firewall rules could be used
  • disable and enable coredumps by renaming files and commenting out a config parameter
  • enable or disable LUKS unlocking with a FIDO2 key or the TPM
  • set capabilities for some binaries for potential future suid replacement. Those binaries will then no longer allow privilege escalation to root that easily
  • restart plasmashell. just a nice shortcut, not security relevant
  • disable USBGuard to workaround potential breakages

missing:

• these build scripts
• these justfiles converted into bash scripts
• hardnened malloc
• pam-authramp
• bubblejail (could be built for EPEL10)
• SELinux policies to confine the binaries spawning user namespaces
• toggle to mount /var/home noexec to make malware harder (with drawbacks, like no firefox binary in a random user dir, no appimages in user dirs, no scripts, python, cargo, go will all not work
• flatpak hardening

https://codeberg.org/HeliumOS/bootc/issues/32 I went through the secureblue configs, selected the ones I use myself, changed some minor things. These changes include - storing scripts in one place, `/usr/local/bin` (allowing root users to delete or change them) - using `/usr/bin/run0` in some of them, some still need to be invoked as root I guess - adding some scripts - separating files like modprobe.d hardening, to make "softening" easier The additions: - add a secureblue license note and attach the Apache 2.0 license text - chronyd config from GrapheneOS - add a few distrobox container configs that use cosign signatures for verification - configure distrobox - create a separate directory per box, $HOME/distrobox/boxname - use the latest Fedora container image by default (needs no maintenance) - modprobe.d - block various commonly unused kernel drivers from loading - separate bluetooth blocking file to make it easy to comment it out to allow it - same for some filesystems that some people might use - additional file to override allow modules if people want that - public cosign keys for various containers to have the root of trust in this OS - SDDM config to use wayland, basic rendering and remove some advanced features for hardening - disable coredump as it allows apps to gain detailed info about the OS - 3 config files, one parameter, see the scripts - not enforced password quality checks - enforce SELinux confinement for chrony (as fas as I understood) and improve behavior when having been killed as it did something bad - various sysctl hardening parameters - systemd resolved: use encrypted DNS opportunistically. This should keep captive portals working, and is vulnerable to downgrade attacks, but probably most usable. Adding a disabled file for real security hardening (with a few set encrypted DNS providers) could be useful - udev: add rules for Google titan and various other HOTP keys for 2FA, including Nitrokey, Solokey, Yubikey - disabled: disable KDE extension support as they are a vector for unchecked executable code ([see issues like this one](https://discuss.kde.org/t/12826/)) - dracut: enable tpm and fido2 for LUKS unlocking - scripts - enable and disable the cups systemd service. Provides easy hardening which can easily be turned off. Alternatively firewall rules could be used - disable and enable coredumps by renaming files and commenting out a config parameter - enable or disable LUKS unlocking with a FIDO2 key or the TPM - set capabilities for some binaries for potential future suid replacement. Those binaries will then no longer allow privilege escalation to root that easily - restart plasmashell. just a nice shortcut, not security relevant - disable USBGuard to workaround potential breakages missing: - [these build scripts](https://github.com/secureblue/secureblue/tree/live/files/scripts) - [these justfiles](https://github.com/secureblue/secureblue/tree/live/files/justfiles) converted into bash scripts - hardnened malloc - pam-authramp - bubblejail (could be built for EPEL10) - SELinux policies to confine the binaries spawning user namespaces - toggle to mount /var/home `noexec` to make malware harder (with drawbacks, like no firefox binary in a random user dir, no appimages in user dirs, no scripts, python, cargo, go will all not work - flatpak hardening

imbev commented 2025年01月23日 22:23:17 +01:00

There are a lot of great things here, thank you for your contributions. My primary feedback is that much of this should be toggled by the user, not default. We could have a master toggle script to apply all of these at once.

storing scripts in one place, /usr/local/bin (allowing root users to delete or change them)

These should be in /usr/bin, following the convention heliumos-<feature>-<enable/disable>. This would also apply to those mentioned below as toggled by script.

modprobe.d

Unless there is a module with a particular security risk or similar factors, these should be the same as upstream by default. We can add a script to toggle a symlink from /usr/share.

chronyd config from GrapheneOS

Are there any downsides to this?

add a few distrobox container configs that use cosign signatures for verification

This should be toggled via a script

create a separate directory per box, $HOME/distrobox/boxname

Should be toggled by script

separate bluetooth blocking file to make it easy to comment it out to allow it

Bluetooth should work by default, we could have a script to toggle

public cosign keys for various containers to have the root of trust in this OS

Should be toggled by script

SDDM config to use wayland, basic rendering and remove some advanced features for hardening

Should be toggled by script

disable coredump as it allows apps to gain detailed info about the OS

Should be toggled by script

not enforced password quality checks

Should be toggled by script

enforce SELinux confinement for chrony (as fas as I understood) and improve behavior when having been killed as it did something bad

Where is this configured? Does this have any downsides?

various sysctl hardening parameters

Those that have no downsides can be enabled by default. Those with a downside (disabling io_uring, etc.) should be toggled by script.

systemd resolved: use encrypted DNS opportunistically. This should keep captive portals working, and is vulnerable to downgrade attacks, but probably most usable. Adding a disabled file for real security hardening (with a few set encrypted DNS providers) could be useful

Does this have any downsides?

disabled: disable KDE extension support as they are a vector for unchecked executable code (see issues like this one)

This can be placed in /usr/share, with a script to toggle a symlink

restart plasmashell. just a nice shortcut, not security relevant

I think this would be better as user customization, not included in the default installation

Great work! Looking forward to a more secure HeliumOS :)

There are a lot of great things here, thank you for your contributions. My primary feedback is that much of this should be toggled by the user, not default. We could have a master toggle script to apply all of these at once. > storing scripts in one place, /usr/local/bin (allowing root users to delete or change them) These should be in /usr/bin, following the convention `heliumos-<feature>-<enable/disable>`. This would also apply to those mentioned below as toggled by script. > modprobe.d Unless there is a module with a particular security risk or similar factors, these should be the same as upstream by default. We can add a script to toggle a symlink from /usr/share. > chronyd config from GrapheneOS Are there any downsides to this? > add a few distrobox container configs that use cosign signatures for verification This should be toggled via a script > create a separate directory per box, $HOME/distrobox/boxname Should be toggled by script > separate bluetooth blocking file to make it easy to comment it out to allow it Bluetooth should work by default, we could have a script to toggle > public cosign keys for various containers to have the root of trust in this OS Should be toggled by script > SDDM config to use wayland, basic rendering and remove some advanced features for hardening Should be toggled by script > disable coredump as it allows apps to gain detailed info about the OS Should be toggled by script > not enforced password quality checks Should be toggled by script > enforce SELinux confinement for chrony (as fas as I understood) and improve behavior when having been killed as it did something bad Where is this configured? Does this have any downsides? > various sysctl hardening parameters Those that have no downsides can be enabled by default. Those with a downside (disabling io_uring, etc.) should be toggled by script. > systemd resolved: use encrypted DNS opportunistically. This should keep captive portals working, and is vulnerable to downgrade attacks, but probably most usable. Adding a disabled file for real security hardening (with a few set encrypted DNS providers) could be useful Does this have any downsides? > disabled: disable KDE extension support as they are a vector for unchecked executable code (see issues like this one) This can be placed in /usr/share, with a script to toggle a symlink > restart plasmashell. just a nice shortcut, not security relevant I think this would be better as user customization, not included in the default installation Great work! Looking forward to a more secure HeliumOS :)

boredsquirrel commented 2025年01月24日 00:13:25 +01:00

I will come back to it. Some things dont need to be toggled I think, others for sure.

Upstream seems to have troubles removing old garbage that is no longer needed, like exotic filesystems. An example here are user namespace apps. If there is a vulnerability in any of those hardly battle-tested filesystems, this can lead to a kernel privesc.

placing stuff in /usr/bin would mean users cannot remove it, is that intended?

I will come back to it. Some things dont need to be toggled I think, others for sure. Upstream seems to have troubles removing old garbage that is no longer needed, like exotic filesystems. An example here are user namespace apps. If there is a vulnerability in any of those hardly battle-tested filesystems, this can lead to a kernel privesc. placing stuff in /usr/bin would mean users cannot remove it, is that intended?

imbev commented 2025年01月24日 00:25:14 +01:00

Upstream seems to have troubles removing old garbage that is no longer needed, like exotic filesystems. An example here are user namespace apps. If there is a vulnerability in any of those hardly battle-tested filesystems, this can lead to a kernel privesc.

That's a good point. I think Podman uses user namespaces, but there should be some modules that users aren't expected to need. Unless I am mistaken, squashfs is needed for appimage and udf for using DVDs. For the rarely used modules, we can disable those by default and include a script to enable.

placing stuff in /usr/bin would mean users cannot remove it, is that intended?

Yes, if the user doesn't need to use the script, they can ignore it.

> Upstream seems to have troubles removing old garbage that is no longer needed, like exotic filesystems. An example here are user namespace apps. If there is a vulnerability in any of those hardly battle-tested filesystems, this can lead to a kernel privesc. That's a good point. I think Podman uses user namespaces, but there should be some modules that users aren't expected to need. Unless I am mistaken, squashfs is needed for appimage and udf for using DVDs. For the rarely used modules, we can disable those by default and include a script to enable. > placing stuff in /usr/bin would mean users cannot remove it, is that intended? Yes, if the user doesn't need to use the script, they can ignore it.

boredsquirrel commented 2025年01月24日 21:39:12 +01:00

so, I will do the following changes:

• disable some hardening like more common filesystems by default
• move all scripts to /usr/bin (tbh I dont like this, as this is also where ALL the OS stuff is)
• make a couple of toggle scripts to enable and disable hardening
• keep a good amount of hardening by default

I am also pro having "everything work" by default. Having options to turn stuff on and off is important.

maybe I do a script with read input where users can make a choice for everything, as a setup.

so, I will do the following changes: - disable some hardening like more common filesystems by default - move all scripts to /usr/bin (tbh I dont like this, as this is also where ALL the OS stuff is) - make a couple of toggle scripts to enable and disable hardening - keep a good amount of hardening by default I am also pro having "everything work" by default. Having options to turn stuff on and off is important. maybe I do a script with `read` input where users can make a choice for everything, as a setup.

boredsquirrel commented 2025年01月24日 21:40:39 +01:00

chronyd config from GrapheneOS

Are there any downsides to this?

no idea but dont assume. I use GrapheneOS daily without issues, and the config is in secureblue also for a while

same for sysctl, where there is a lot of stuff I dont know

I have used secureblue and it works just fine. I left out some things on purpose, like just overwriting the default firewalld configs (so you need to enable EVERYTHING manually)

> > chronyd config from GrapheneOS > Are there any downsides to this? no idea but dont assume. I use GrapheneOS daily without issues, and the config is in secureblue also for a while same for sysctl, where there is a lot of stuff I dont know I have used secureblue and it works just fine. I left out some things on purpose, like just overwriting the default firewalld configs (so you need to enable EVERYTHING manually)

boredsquirrel commented 2025年01月24日 21:42:14 +01:00

In the end, documentation here in the repo, or better on the website, and maybe an /etc/motd would be nice.

ublue has a nice implementation of the motd which shows you some commands and you can turn it off

In the end, documentation here in the repo, or better on the website, and maybe an `/etc/motd` would be nice. ublue has a nice implementation of the motd which shows you some commands and you can turn it off

imbev commented 2025年01月24日 22:32:08 +01:00

move all scripts to /usr/bin (tbh I dont like this, as this is also where ALL the OS stuff is)

Normally I would agree, but from the perspective of the end-user, the scripts are part of the OS.

maybe I do a script with read input where users can make a choice for everything, as a setup.

That would be great. Feel free to use Python for that.

No idea but dont assume. I use GrapheneOS daily without issues, and the config is in secureblue also for a while

In that case, we can keep the cronyd configuration that you added.

same for sysctl, where there is a lot of stuff I dont know

We can keep most of the sysctl config as is, but core dump and io_uring should be enabled by default. You can symlink/delete a second configuration file for those two, toggled by a script.

In the end, documentation here in the repo, or better on the website, and maybe an /etc/motd would be nice.

ublue has a nice implementation of the motd which shows you some commands and you can turn it off

That would be a great improvement. I'll open an issue, and we can add that in another branch.

> move all scripts to /usr/bin (tbh I dont like this, as this is also where ALL the OS stuff is) Normally I would agree, but from the perspective of the end-user, the scripts are part of the OS. > maybe I do a script with read input where users can make a choice for everything, as a setup. That would be great. Feel free to use Python for that. > No idea but dont assume. I use GrapheneOS daily without issues, and the config is in secureblue also for a while In that case, we can keep the cronyd configuration that you added. > same for sysctl, where there is a lot of stuff I dont know We can keep most of the sysctl config as is, but core dump and io_uring should be enabled by default. You can symlink/delete a second configuration file for those two, toggled by a script. > In the end, documentation here in the repo, or better on the website, and maybe an /etc/motd would be nice. > ublue has a nice implementation of the motd which shows you some commands and you can turn it off That would be a great improvement. I'll open an issue, and we can add that in another branch.

imbev commented 2025年01月24日 23:37:40 +01:00

MOTD: #46

MOTD: https://codeberg.org/HeliumOS/bootc/issues/46

boredsquirrel commented 2025年01月29日 19:16:54 +01:00

@imbev update:

I have tiny experience in python haha, I stay with bash.

I have separated out the modprobe.d into files that build logical groups. It is not great, but the toggle mechanism is really simple by just renaming the files to disable them. At least the modprobe manpage says that this disables the files from loading. The secureblue approach is pretty messy here, I may do a PR on their implementation too (which we figured out at the time, like the hacky bluetooth disabling mode). I also took your "make DVDs work" thing into consideration and grouped those.

Added a lot of small scripts, starting with the name of the thing, and then the job. Either "setup" (interactive), "toggle" (automatic on/off", or "on"/"off" (one way). That is still not the same everywhere I see, like "harden kargs" (which is more "english grammer"), would you change that?

These individual scripts can then be used in an initial setup thing, which makes that script way easier to deal with, and it makes it easy to understand.

I will add more READMEs etc, as they can just be placed everywhere.

Then in the end a setup thing, best would be graphical, but with the bash scripts this is probably easy? Havent done GUI programming yet.

core dump and io_uring should be enabled by default

coredump is now part of a group of configs "debugging" which can be enabled and disabled and is enabled by default.

not sure what io_uring is.

@imbev update: I have tiny experience in python haha, I stay with bash. I have separated out the modprobe.d into files that build logical groups. It is not great, but the toggle mechanism is really simple by just renaming the files to disable them. At least the modprobe manpage says that this disables the files from loading. The secureblue approach is pretty messy here, I may do a PR on their implementation too (which we figured out at the time, like the hacky bluetooth disabling mode). I also took your "make DVDs work" thing into consideration and grouped those. Added a lot of small scripts, starting with the name of the thing, and then the job. Either "setup" (interactive), "toggle" (automatic on/off", or "on"/"off" (one way). That is still not the same everywhere I see, like "harden kargs" (which is more "english grammer"), would you change that? These individual scripts can then be used in an initial setup thing, which makes that script way easier to deal with, and it makes it easy to understand. I will add more READMEs etc, as they can just be placed everywhere. Then in the end a setup thing, best would be graphical, but with the bash scripts this is probably easy? Havent done GUI programming yet. > core dump and io_uring should be enabled by default coredump is now part of a group of configs "debugging" which can be enabled and disabled and is enabled by default. not sure what io_uring is.

imbev commented 2025年01月30日 02:53:09 +01:00

I have tiny experience in python haha, I stay with bash.

That should be fine if each script stays simple :)

I have separated out the modprobe.d into files that build logical groups. It is not great, but the toggle mechanism is really simple by just renaming the files to disable them. At least the modprobe manpage says that this disables the files from loading. The secureblue approach is pretty messy here, I may do a PR on their implementation too (which we figured out at the time, like the hacky bluetooth disabling mode). I also took your "make DVDs work" thing into consideration and grouped those.

Added a lot of small scripts, starting with the name of the thing, and then the job. Either "setup" (interactive), "toggle" (automatic on/off", or "on"/"off" (one way). That is still not the same everywhere I see, like "harden kargs" (which is more "english grammer"), would you change that?

Yes, the scripts should be named heliumos-<name>-enable/disable. One goal is idempotence.

These individual scripts can then be used in an initial setup thing, which makes that script way easier to deal with, and it makes it easy to understand.

That's an improvement, though I will make some changes myself. Rather than moving/symlinking between 2 files in /etc, it would be ideal to symlink/delete symlink files from /usr into /etc or /var.

I see that kargs are managed via rpm-ostree. There might be a better way to do so, perhaps a few symlink from /var into /usr/lib/bootc/kargs.d, with those symlink targets as symlinks from /usr. Something like /var/heliumos/kargs-hardened.toml -> /usr/lib/bootc/kargs.d, with either an empty file at /var/heliumos/kargs-hardened.toml or /var/heliumos/kargs-hardened.toml -> /usr/share/heliumos/kargs-hardened.toml depending on a couple of scripts.

https://containers.github.io/bootc/building/kernel-arguments.html

Then in the end a setup thing, best would be graphical, but with the bash scripts this is probably easy? Havent done GUI programming yet.

It wouldn't be too difficult, but the scripts should be non-interactive for this to work.

not sure what io_uring is.

Interface for async functionality, used by much software

> I have tiny experience in python haha, I stay with bash. That should be fine if each script stays simple :) > I have separated out the modprobe.d into files that build logical groups. It is not great, but the toggle mechanism is really simple by just renaming the files to disable them. At least the modprobe manpage says that this disables the files from loading. The secureblue approach is pretty messy here, I may do a PR on their implementation too (which we figured out at the time, like the hacky bluetooth disabling mode). I also took your "make DVDs work" thing into consideration and grouped those. > Added a lot of small scripts, starting with the name of the thing, and then the job. Either "setup" (interactive), "toggle" (automatic on/off", or "on"/"off" (one way). That is still not the same everywhere I see, like "harden kargs" (which is more "english grammer"), would you change that? Yes, the scripts should be named `heliumos-<name>-enable/disable`. One goal is idempotence. > These individual scripts can then be used in an initial setup thing, which makes that script way easier to deal with, and it makes it easy to understand. That's an improvement, though I will make some changes myself. Rather than moving/symlinking between 2 files in /etc, it would be ideal to symlink/delete symlink files from /usr into /etc or /var. I see that kargs are managed via rpm-ostree. There might be a better way to do so, perhaps a few symlink from /var into /usr/lib/bootc/kargs.d, with those symlink targets as symlinks from /usr. Something like `/var/heliumos/kargs-hardened.toml -> /usr/lib/bootc/kargs.d`, with either an empty file at `/var/heliumos/kargs-hardened.toml` or `/var/heliumos/kargs-hardened.toml -> /usr/share/heliumos/kargs-hardened.toml` depending on a couple of scripts. https://containers.github.io/bootc/building/kernel-arguments.html > Then in the end a setup thing, best would be graphical, but with the bash scripts this is probably easy? Havent done GUI programming yet. It wouldn't be too difficult, but the scripts should be non-interactive for this to work. > not sure what io_uring is. Interface for async functionality, used by much software

imbev commented 2025年01月30日 03:30:50 +01:00

Here's a diff that refactors the enable/disable of coredump

diff --git a/10/system_root/etc/profile.d/heliumos-feature-path.sh b/10/system_root/etc/profile.d/heliumos-feature-path.sh
new file mode 100755
index 0000000..ec02de9
--- /dev/null
+++ b/10/system_root/etc/profile.d/heliumos-feature-path.sh
@@ -0,0 +1,3 @@
+#!/usr/bin/env bash
+
+export PATH=$PATH:/usr/bin/heliumos
diff --git a/10/system_root/usr/bin/heliumos/heliumos-coredump-disable b/10/system_root/usr/bin/heliumos/heliumos-coredump-disable
new file mode 100644
index 0000000..4ca296a
--- /dev/null
+++ b/10/system_root/usr/bin/heliumos/heliumos-coredump-disable
@@ -0,0 +1,23 @@
+#!/usr/bin/run0 bash
+
+set -euo pipefail
+
+echo "HeliumOS: Disabling coredump"
+
+ln -sf \
+ /usr/share/heliumos/features/core_dump/systemd_user.conf \
+ /etc/systemd/user.conf.d/heliumos-coredump-disable.conf
+
+ln -sf \
+ /usr/share/heliumos/features/core_dump/systemd_system.conf \
+ /etc/systemd/system.conf.d/heliumos-coredump-disable.conf
+
+ln -sf \
+ /usr/share/heliumos/features/core_dump/security_limits.conf \
+ /etc/security/limits.d/50-heliumos-coredump-disable.conf
+
+ln -sf \
+ /usr/share/heliumos/features/core_dump/sysctl.conf \
+ /etc/sysctl.d/heliumos-coredump-disable.conf
+
+echo "--Complete--"
diff --git a/10/system_root/usr/bin/heliumos/heliumos-coredump-enable b/10/system_root/usr/bin/heliumos/heliumos-coredump-enable
new file mode 100644
index 0000000..e37777f
--- /dev/null
+++ b/10/system_root/usr/bin/heliumos/heliumos-coredump-enable
@@ -0,0 +1,19 @@
+#!/usr/bin/run0 bash
+
+set -euo pipefail
+
+echo "HeliumOS: Enable coredump (Default)"
+
+rm -rf \
+ /etc/systemd/user.conf.d/heliumos-coredump-disable.conf
+
+rm -rf \
+ /etc/systemd/system.conf.d/heliumos-coredump-disable.conf
+
+rm -rf \
+ /etc/security/limits.d/50-heliumos-coredump-disable.conf
+
+rm -rf \
+ /etc/sysctl.d/heliumos-coredump-disable.conf
+
+echo "--Complete--"
diff --git a/10/system_root/usr/share/heliumos/feature/core_dump/security_limits.conf b/10/system_root/usr/share/heliumos/feature/core_dump/security_limits.conf
new file mode 100644
index 0000000..ced6635
--- /dev/null
+++ b/10/system_root/usr/share/heliumos/feature/core_dump/security_limits.conf
@@ -0,0 +1,2 @@
+* hard core 0
+* soft core 0
diff --git a/10/system_root/usr/share/heliumos/feature/core_dump/sysctl.conf b/10/system_root/usr/share/heliumos/feature/core_dump/sysctl.conf
new file mode 100644
index 0000000..f54927f
--- /dev/null
+++ b/10/system_root/usr/share/heliumos/feature/core_dump/sysctl.conf
@@ -0,0 +1 @@
+kernel.core_pattern = |/bin/false
diff --git a/10/system_root/usr/share/heliumos/feature/core_dump/systemd_system.conf b/10/system_root/usr/share/heliumos/feature/core_dump/systemd_system.conf
new file mode 100644
index 0000000..08e76b6
--- /dev/null
+++ b/10/system_root/usr/share/heliumos/feature/core_dump/systemd_system.conf
@@ -0,0 +1,2 @@
+[Manager]
+DumpCore=no
diff --git a/10/system_root/usr/share/heliumos/feature/core_dump/systemd_user.conf b/10/system_root/usr/share/heliumos/feature/core_dump/systemd_user.conf
new file mode 100644
index 0000000..08e76b6
--- /dev/null
+++ b/10/system_root/usr/share/heliumos/feature/core_dump/systemd_user.conf
@@ -0,0 +1,2 @@
+[Manager]
+DumpCore=no

Here's a diff that refactors the enable/disable of coredump ``` diff --git a/10/system_root/etc/profile.d/heliumos-feature-path.sh b/10/system_root/etc/profile.d/heliumos-feature-path.sh new file mode 100755 index 0000000..ec02de9 --- /dev/null +++ b/10/system_root/etc/profile.d/heliumos-feature-path.sh @@ -0,0 +1,3 @@ +#!/usr/bin/env bash + +export PATH=$PATH:/usr/bin/heliumos diff --git a/10/system_root/usr/bin/heliumos/heliumos-coredump-disable b/10/system_root/usr/bin/heliumos/heliumos-coredump-disable new file mode 100644 index 0000000..4ca296a --- /dev/null +++ b/10/system_root/usr/bin/heliumos/heliumos-coredump-disable @@ -0,0 +1,23 @@ +#!/usr/bin/run0 bash + +set -euo pipefail + +echo "HeliumOS: Disabling coredump" + +ln -sf \ + /usr/share/heliumos/features/core_dump/systemd_user.conf \ + /etc/systemd/user.conf.d/heliumos-coredump-disable.conf + +ln -sf \ + /usr/share/heliumos/features/core_dump/systemd_system.conf \ + /etc/systemd/system.conf.d/heliumos-coredump-disable.conf + +ln -sf \ + /usr/share/heliumos/features/core_dump/security_limits.conf \ + /etc/security/limits.d/50-heliumos-coredump-disable.conf + +ln -sf \ + /usr/share/heliumos/features/core_dump/sysctl.conf \ + /etc/sysctl.d/heliumos-coredump-disable.conf + +echo "--Complete--" diff --git a/10/system_root/usr/bin/heliumos/heliumos-coredump-enable b/10/system_root/usr/bin/heliumos/heliumos-coredump-enable new file mode 100644 index 0000000..e37777f --- /dev/null +++ b/10/system_root/usr/bin/heliumos/heliumos-coredump-enable @@ -0,0 +1,19 @@ +#!/usr/bin/run0 bash + +set -euo pipefail + +echo "HeliumOS: Enable coredump (Default)" + +rm -rf \ + /etc/systemd/user.conf.d/heliumos-coredump-disable.conf + +rm -rf \ + /etc/systemd/system.conf.d/heliumos-coredump-disable.conf + +rm -rf \ + /etc/security/limits.d/50-heliumos-coredump-disable.conf + +rm -rf \ + /etc/sysctl.d/heliumos-coredump-disable.conf + +echo "--Complete--" diff --git a/10/system_root/usr/share/heliumos/feature/core_dump/security_limits.conf b/10/system_root/usr/share/heliumos/feature/core_dump/security_limits.conf new file mode 100644 index 0000000..ced6635 --- /dev/null +++ b/10/system_root/usr/share/heliumos/feature/core_dump/security_limits.conf @@ -0,0 +1,2 @@ +* hard core 0 +* soft core 0 diff --git a/10/system_root/usr/share/heliumos/feature/core_dump/sysctl.conf b/10/system_root/usr/share/heliumos/feature/core_dump/sysctl.conf new file mode 100644 index 0000000..f54927f --- /dev/null +++ b/10/system_root/usr/share/heliumos/feature/core_dump/sysctl.conf @@ -0,0 +1 @@ +kernel.core_pattern = |/bin/false diff --git a/10/system_root/usr/share/heliumos/feature/core_dump/systemd_system.conf b/10/system_root/usr/share/heliumos/feature/core_dump/systemd_system.conf new file mode 100644 index 0000000..08e76b6 --- /dev/null +++ b/10/system_root/usr/share/heliumos/feature/core_dump/systemd_system.conf @@ -0,0 +1,2 @@ +[Manager] +DumpCore=no diff --git a/10/system_root/usr/share/heliumos/feature/core_dump/systemd_user.conf b/10/system_root/usr/share/heliumos/feature/core_dump/systemd_user.conf new file mode 100644 index 0000000..08e76b6 --- /dev/null +++ b/10/system_root/usr/share/heliumos/feature/core_dump/systemd_user.conf @@ -0,0 +1,2 @@ +[Manager] +DumpCore=no ```

imbev commented 2025年01月30日 03:36:13 +01:00

cups-toggle is redundant, it's a simple systemctl enable/disable cups.service

cups-toggle is redundant, it's a simple `systemctl enable/disable cups.service`

imbev commented 2025年01月30日 03:37:25 +01:00

restart-plasma also, systemctl restart sddm.service

restart-plasma also, `systemctl restart sddm.service`

imbev commented 2025年01月30日 03:57:50 +01:00

usbguard diff

diff --git a/10/system_root/usr/bin/heliumos/heliumos-usbguard-disable b/10/system_root/usr/bin/heliumos/heliumos-usbguard-disable
new file mode 100755
index 0000000..b04d705
--- /dev/null
+++ b/10/system_root/usr/bin/heliumos/heliumos-usbguard-disable
@@ -0,0 +1,13 @@
+#!/usr/bin/run0 bash
+
+set -euo pipefail
+
+echo "HeliumOS: Disabling usbguard"
+
+systemctl disable --now usbguard.service
+
+rm -rf \
+ /var/log/usbguard
+ /etc/usbguard
+
+echo "--Complete--"
diff --git a/10/system_root/usr/bin/setup-usbguard b/10/system_root/usr/bin/heliumos/heliumos-usbguard-enable
similarity index 85%
rename from 10/system_root/usr/bin/setup-usbguard
rename to 10/system_root/usr/bin/heliumos/heliumos-usbguard-enable
index a59e103..614846e 100755
--- a/10/system_root/usr/bin/setup-usbguard
+++ b/10/system_root/usr/bin/heliumos/heliumos-usbguard-enable
@@ -1,9 +1,12 @@
-#!/usr/bin/bash
+#!/usr/bin/env bash
 
 set -euo pipefail
 
+echo "HeliumOS: Enabling usbguard"
 echo "Notice: This will generate a policy based on your existing connected USB devices."
+
 run0 sh -c '
+
 mkdir -p /var/log/usbguard
 mkdir -p /etc/usbguard
 chmod 755 /etc/usbguard
@@ -12,5 +15,7 @@ run0 sh -c '
 restorecon -vR /var/log/usbguard
 systemctl enable --now usbguard.service
 usbguard add-user 1ドル
+
 ' -- $USER
-systemctl enable --user --now usbguard-notifier.service
+
+echo "--Complete--"
diff --git a/10/system_root/usr/bin/usbguard-off b/10/system_root/usr/bin/usbguard-off
deleted file mode 100755
index 3e489ac..0000000
--- a/10/system_root/usr/bin/usbguard-off
+++ /dev/null
@@ -1,17 +0,0 @@
-#!/bin/bash
-
-# set all USB devices to allowed
-# for i in /sys/bus/usb/devices/**/authorized_default; do echo 1 > $i; done
-
-# temporarily allow everything
-usbguard set-parameter ImplicitPolicyTarget allow
-
-cat <<EOF
-
-USBGuard allows all USB devices
-
-Use this command to block them by default again:
-
-usbguard set-parameter ImplicitPolicyTarget block
-
-EOF

usbguard diff ``` diff --git a/10/system_root/usr/bin/heliumos/heliumos-usbguard-disable b/10/system_root/usr/bin/heliumos/heliumos-usbguard-disable new file mode 100755 index 0000000..b04d705 --- /dev/null +++ b/10/system_root/usr/bin/heliumos/heliumos-usbguard-disable @@ -0,0 +1,13 @@ +#!/usr/bin/run0 bash + +set -euo pipefail + +echo "HeliumOS: Disabling usbguard" + +systemctl disable --now usbguard.service + +rm -rf \ + /var/log/usbguard + /etc/usbguard + +echo "--Complete--" diff --git a/10/system_root/usr/bin/setup-usbguard b/10/system_root/usr/bin/heliumos/heliumos-usbguard-enable similarity index 85% rename from 10/system_root/usr/bin/setup-usbguard rename to 10/system_root/usr/bin/heliumos/heliumos-usbguard-enable index a59e103..614846e 100755 --- a/10/system_root/usr/bin/setup-usbguard +++ b/10/system_root/usr/bin/heliumos/heliumos-usbguard-enable @@ -1,9 +1,12 @@ -#!/usr/bin/bash +#!/usr/bin/env bash set -euo pipefail +echo "HeliumOS: Enabling usbguard" echo "Notice: This will generate a policy based on your existing connected USB devices." + run0 sh -c ' + mkdir -p /var/log/usbguard mkdir -p /etc/usbguard chmod 755 /etc/usbguard @@ -12,5 +15,7 @@ run0 sh -c ' restorecon -vR /var/log/usbguard systemctl enable --now usbguard.service usbguard add-user 1ドル + ' -- $USER -systemctl enable --user --now usbguard-notifier.service + +echo "--Complete--" diff --git a/10/system_root/usr/bin/usbguard-off b/10/system_root/usr/bin/usbguard-off deleted file mode 100755 index 3e489ac..0000000 --- a/10/system_root/usr/bin/usbguard-off +++ /dev/null @@ -1,17 +0,0 @@ -#!/bin/bash - -# set all USB devices to allowed -# for i in /sys/bus/usb/devices/**/authorized_default; do echo 1 > $i; done - -# temporarily allow everything -usbguard set-parameter ImplicitPolicyTarget allow - -cat <<EOF - -USBGuard allows all USB devices - -Use this command to block them by default again: - -usbguard set-parameter ImplicitPolicyTarget block - -EOF ```

boredsquirrel commented 2025年01月31日 21:18:29 +01:00

@imbev wrote in #43 (comment):

cups-toggle is redundant, it's a simple systemctl enable/disable cups.service

It is a bit more than that and works noninteractively. It also masks the service which is useful to be protected against GUI stuff enabling it again.

@imbev wrote in #43 (comment):

restart-plasma also, systemctl restart sddm.service

This would be plasmashell.service I think, and simply makes things easier. Not essential for sure.

---

I will see how I apply those diffs.

Placing kargs in /usr sounds like a bad idea as they should be possible to disable. The rpm-ostree approach is fine I think.

So all scripts should be called heliumos-name-function ?

@imbev wrote in https://codeberg.org/HeliumOS/bootc/pulls/43#issuecomment-2661549: > cups-toggle is redundant, it's a simple `systemctl enable/disable cups.service` It is a bit more than that and works noninteractively. It also masks the service which is useful to be protected against GUI stuff enabling it again. @imbev wrote in https://codeberg.org/HeliumOS/bootc/pulls/43#issuecomment-2661550: > restart-plasma also, `systemctl restart sddm.service` This would be plasmashell.service I think, and simply makes things easier. Not essential for sure. --- I will see how I apply those diffs. Placing kargs in /usr sounds like a bad idea as they should be possible to disable. The rpm-ostree approach is fine I think. So all scripts should be called heliumos-name-function ?

imbev commented 2025年01月31日 21:27:42 +01:00

It is a bit more than that and works noninteractively. It also masks the service which is useful to be protected against GUI stuff enabling it again.

Good point. It should be split into a couple of scripts, but we can otherwise keep it.

Placing kargs in /usr sounds like a bad idea as they should be possible to disable. The rpm-ostree approach is fine I think.

I see. rpm-ostree should be stable within EL10, so we can keep that.

So all scripts should be called heliumos-name-function ?

Yes, with function being either "enable" or "disable".

> It is a bit more than that and works noninteractively. It also masks the service which is useful to be protected against GUI stuff enabling it again. Good point. It should be split into a couple of scripts, but we can otherwise keep it. > Placing kargs in /usr sounds like a bad idea as they should be possible to disable. The rpm-ostree approach is fine I think. I see. rpm-ostree should be stable within EL10, so we can keep that. > So all scripts should be called heliumos-name-function ? Yes, with function being either "enable" or "disable".

boredsquirrel commented 2025年02月01日 20:40:30 +01:00

okay so all scripts converted to simple on/off scripts?

Will do that. And find out how to apply patches in git, but they are just renamings right? Done that already.

btw, I am only working on the 10 branch currently. Those things should all be version-independent though. Moving them to a separate "shared files" directory might be better.

okay so all scripts converted to simple on/off scripts? Will do that. And find out how to apply patches in git, but they are just renamings right? Done that already. btw, I am only working on the 10 branch currently. Those things should all be version-independent though. Moving them to a separate "shared files" directory might be better.

boredsquirrel commented 2025年02月01日 20:51:32 +01:00

I renamed them and separated them to be either "enable", "disable" or "setup"

I renamed them and separated them to be either "enable", "disable" or "setup"

boredsquirrel commented 2025年02月02日 16:21:28 +01:00

I think it would make sense to create a separate directory

files
 security
 ...

that will also contain a root fs structure and contain these things

I think it would make sense to create a separate directory ``` files security ... ``` that will also contain a root fs structure and contain these things

imbev commented 2025年02月02日 18:03:50 +01:00

btw, I am only working on the 10 branch currently. Those things should all be version-independent though. Moving them to a separate "shared files" directory might be better.

For now, they should be kept within the 10 directory. We need to be careful about major EL versions, however we might find some configuration that is practically frozen going forward and can be extracted into a shared directory.

I renamed them and separated them to be either "enable", "disable" or "setup"

Can you merge the enable and setup scripts? The ideal is idempotence, with enable fully setting up and enabling the feature, disable fully removing and disabling the feature. The only exception would be if the setup was particularly expensive, such as a multi gb download.

I think it would make sense to create a separate directory

that will also contain a root fs structure and contain these things

If you take a closer look at the diffs, you'll notice that I placed such files in their own directories: 10/system_root/usr/share/heliumos/feature/core_dump/security_limits.conf

The debugging hardening feature has a somewhat ambiguous name. Does disable disable the hardening, or does disable disable the debugging? It may be beneficial to separate this into more fine-grained "features" such as "core_dump".

> btw, I am only working on the 10 branch currently. Those things should all be version-independent though. Moving them to a separate "shared files" directory might be better. For now, they should be kept within the 10 directory. We need to be careful about major EL versions, however we might find some configuration that is practically frozen going forward and can be extracted into a shared directory. > I renamed them and separated them to be either "enable", "disable" or "setup" Can you merge the enable and setup scripts? The ideal is idempotence, with enable fully setting up and enabling the feature, disable fully removing and disabling the feature. The only exception would be if the setup was particularly expensive, such as a multi gb download. > I think it would make sense to create a separate directory > that will also contain a root fs structure and contain these things If you take a closer look at the diffs, you'll notice that I placed such files in their own directories: `10/system_root/usr/share/heliumos/feature/core_dump/security_limits.conf` The debugging hardening feature has a somewhat ambiguous name. Does disable disable the hardening, or does disable disable the debugging? It may be beneficial to separate this into more fine-grained "features" such as "core_dump".

imbev commented 2025年02月02日 18:08:16 +01:00

For the encrypted swap, please rename the file so that the "encrypted-swap" becomes "encrypted_swap" and "setup" is "enable".

We also need a disable script for that. See my comment in the other issue.

#50 (comment)

For the encrypted swap, please rename the file so that the "encrypted-swap" becomes "encrypted_swap" and "setup" is "enable". We also need a disable script for that. See my comment in the other issue. https://codeberg.org/HeliumOS/bootc/issues/50#issuecomment-2674127

imbev commented 2025年02月02日 18:11:05 +01:00

We expanded scope by adding encrypted swap. In order to merge sometime soon, we'll need to keep our scope from expanding too much.

Additional hardening not already mentioned in this issue should be added in a later PR, this branch has already diverged from dev quite a lot.

We expanded scope by adding encrypted swap. In order to merge sometime soon, we'll need to keep our scope from expanding too much. Additional hardening not already mentioned in this issue should be added in a later PR, this branch has already diverged from dev quite a lot.

boredsquirrel commented 2025年02月07日 17:58:02 +01:00

yes I will see that we find a solution to disable encrypted swap

like, technically that should be just possible, but if it is stable there should be no reason to do so

also the question is, if encrypted swap couldnt be set in the installer process. but that is out of scope for sure

yes I will see that we find a solution to disable encrypted swap like, technically that should be just possible, but if it is stable there should be no reason to do so also the question is, if encrypted swap couldnt be set in the installer process. but that is out of scope for sure

boredsquirrel commented 2025年02月07日 17:58:50 +01:00

and what about the general configs. should I make a separate folder for 9 and 10 settings?

and what about the general configs. should I make a separate folder for 9 and 10 settings?

imbev commented 2025年02月09日 00:28:59 +01:00

and what about the general configs. should I make a separate folder for 9 and 10 settings?

Support for 9 has been dropped, you can keep it in just 10. Note that #49 is moving forward, so it will be necessary to migrate from scripts to justfiles at some point.

> and what about the general configs. should I make a separate folder for 9 and 10 settings? Support for 9 has been dropped, you can keep it in just 10. Note that #49 is moving forward, so it will be necessary to migrate from scripts to justfiles at some point.

boredsquirrel commented 2025年02月11日 12:44:25 +01:00

I removed the encrypted swap scripts for now, but made a script to disable it. It is not tested at all, so I think it makes sense to leave it out for now.

I agree that joining ublue sounds reasonable. But I dont know their stance on hardening, and their images are a bit bloated for my taste.

For now I think this is done, unless you want me to convert the scripts to justfiles. These should be separate though, as having a monolithic one is awful.

kinda like this

https://github.com/secureblue/secureblue/tree/live/files/justfiles

I removed the encrypted swap scripts for now, but made a script to disable it. It is not tested at all, so I think it makes sense to leave it out for now. I agree that joining ublue sounds reasonable. But I dont know their stance on hardening, and their images are a bit bloated for my taste. For now I think this is done, unless you want me to convert the scripts to justfiles. These should be separate though, as having a monolithic one is awful. kinda like this https://github.com/secureblue/secureblue/tree/live/files/justfiles

imbev commented 2025年02月11日 18:19:36 +01:00

I agree that joining ublue sounds reasonable. But I dont know their stance on hardening, and their images are a bit bloated for my taste.

Aurora Helium will be relatively less bloated compared to other images.

For now I think this is done, unless you want me to convert the scripts to justfiles. These should be separate though, as having a monolithic one is awful.

Either is fine. They will be converted to justfiles when added to the new image.

> I agree that joining ublue sounds reasonable. But I dont know their stance on hardening, and their images are a bit bloated for my taste. Aurora Helium will be relatively less bloated compared to other images. > For now I think this is done, unless you want me to convert the scripts to justfiles. These should be separate though, as having a monolithic one is awful. Either is fine. They will be converted to justfiles when added to the new image.

This pull request has changes conflicting with the target branch.