Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)MG
Posts
17
Comments
428
Joined
1 mo. ago

  • Thanks for the tip, love Capy.

    You're right, Whonix is probably the better idea. I use kick secure now but if I move to Qubes then I'll use Whonix as a default.

    I'll have to read more about secureblue. I haven't given the documentation as much time as I should have. I guess you could run an HVM for now.

    Why do you rank secureblue over Whonix?

  • Hey, I recognise you now! That was a great post, I had a lot of fun reading it. If I could follow people on Lemmy I'd follow you.

    What do you think about Kicksecure (and Kicksecure inside of Qubes)? I know they are criticised for backports but leaving that issue aside, I think they have created a very handy distro. I personally go through CIS benchmarks for most of stuff including Kicksecure but it's definitely nice to have a prey hardened distro (SecureBlue too but I hear SecureBlue isn't a big team, not sure how much time they have to address the broad range of desktop Linux security issues).

    Honestly, Qubes is the best at this by far. Their method of compartmentalisation takes away the complexity of reasonable security from the end-user making it a mostly seamless experience. I personally think that if you were to put GrapheneOS and Qubes OS side-by-side on uncompromised hardware, I'd take Qubes. I'd run GrapheneOS inside Qubes with a software/hardware TPM passed through if I could.

  • You can never be private with any device that can connect to the internet out of its own volition. Ubiquity, Alta Labs and Mikrotik should never be trusted unless you're OK with your data potentially ending up on their servers.

    With that said, you can manually upgrade Mikrotik software and selfhost the Mikrotik CHR, Ubiquity controller and Alta Labs controller for a fee (for the latter), which should then in theory invalidate this argument. Even then, I do not trust non-FOSS software for such critical infrastructure so it's still too much for me, but depending on your risk tolerance this might be a good compromise. I would suggest you to look at Mikrotik seriously - their UI might suck but their hardware and software capabilities are FAR beyond what Ubiquity offers for the same price.

    If you want to be private you should get an old computer, buy quad port NIC cards from EBay and run a Linux/BSD router on your own hardware. But that's not the most friendly way to do it so I don't blame anyone for looking away

  • Thanks. You are correct, however since root is required for certain processes, I will use different users and doas for my needs.

    I have realised that it is hard for me to justify the reason why I want to harden an OS for personal use. I gave privilege escalation out, but after reading your comment I have realised that that is not the only thing I am looking to "fix". My intention with running hardened_malloc was to prevent DoS attacks by malicious applications trying to exploit unknown buffer overflow situations, and LibreSSL and musl were to reduce the attack surface.

    I agree with your comment though. I'm just wondering about how I can specify a reason (and why such a reason is required to justify hardening of a distro). I haven't found much of a reason for the existence of OpenBSD, Kicksecure, Qubes etc other than general hardening and security.

  • Thank you for that. Yes, I only really follow his post roughly.

    Unfortunately, I don't think secureblue is going to be a possible choice. I like the secureblue project, I think it's awesome but what I'm working with will likely only come with a Rocky/AlmaLinux base.

  • You raise a valid point. In which case, I want to try and prevent malicious privilege escalation by a process on this system. I know that's a broad topic and depends on the application being run, but most of the tweaks I've listed work towards that to an extent.

    To be precise, I'm asking how to harden the upcoming AlmaLinux based Dom0 by the XCP-NG project. I want my system to be difficult to work with even if someone breaks into it (unlikely because I trust Xen as a hypervisor platform but still).

    I admit I was a bit surprised by the question since I've never consciously thought about a reason to harden my OS. I always just want to do it and wonder why OSes aren't hardened more by default.

  • Thank you for the note. I'm been cursing myself for not being able to provide my devs with something similar (they don't complain but I know it will make their lives easier). I will start nix from scratch if I learn it but nixops definitely seems like it can help because terraform isn't that great at the example you provided. Thanks.

    focused on security hardening

    Could you elaborate?

  • I am serious. I am a cloud engineer (glorified system admin for cloud + Linux VMs) and I'm still stuck on Ansible + Terraform (stuck isn't the right word, we are a RHEL and Alpine shop for our VMs and Containers and things work well enough). My friends in bigger companies are using Nix though, but I was always scared of the learning curve. I want to see clear benefits of using nix so I can push myself to actually learn it, which is why I asked. Thanks for the link.