I don’t see why it should presuppose non-root access. What I meant above about shred was local access, not root. Shred would only really help if someone is doing forensics analysis on your hard drive.
A lot mixed in here to easily talk past each other.
system map access generally:
root compromise: If there is root access (root user compromise from
remote), why would anyone still care about system map?
non-root user compromise: I.e. a malware process is running under a
linux user account such as user apache2 or so. In that case, the malware
being unable to read system map, might help to prevent the attacker from
escalating to compromise.
If these assumptions are right, then setting access rights to system map
to root only would complicate non-root to root escalation for malware.
system map file recovery by malware:
File recovery tools can be run root or non-root users?
If only by root users: great.
If also by non-root users: bad, because then malware could use undelete
tools to re-creating system map file.
File recovery tools don’t necessarily require local (as in hands on) access.
It doesn’t necessarily have to be full root access. It could just be e.g. a compromised service with only CAP_DAC_OVERRIDE. Many do use that capability.
Oh, I’ve never messed around with those before and I thought they required local access.
If the system map files can be recovered remotely, then we can just switch the rm with shred -zu in the script.
Most seem to be kernel config options. Not things that can be changed via sysctl or boot parameters.
One that does look interesting though is page_alloc.shuffle=1 although this is only for later kernel versions. Debian will likely enable this by default once it comes.
There’s nothing here we don’t already do or would require a custom kernel.
Also, Copperhead is not a good source anymore after they kicked out Daniel Micay and started scamming users.
There’s nothing here we don’t already do or would require a custom kernel.
Also, Copperhead is not a good source anymore after they kicked out Daniel Micay and started scamming users.
I didn’t follow these developments. However, possibly these these
websites are still the same as created by Daniel Micay and never updated
since. Also, we’d use them as as inspiration (like from any source
anyway), and then independently verify all claims (before we make
changes on our side) not for face value.
I just wanted to point out in folder /etc/default/grub.d/40_kernel_hardening.cfg, there is this entry: “slab_debug=FZP”
Should it be “slub_debug=FZP” instead?
Sure thing! I have many same harden features on my host and see (on host) that the slab_nomerge setting is used together with slub_debug=FZP (and also page_poison=1)
I found an excellent write-up on Tails site in this documentation section
This guide has some interesting stuff although I’m not sure I’d trust someone to give an informed opinion on security when they’re using leetspeak and saying stuff like “S0rry. I barely use SELinux for reasons. The 1st one is I don’t trust NSA”.
There is some interesting anti-DDoS sysctl settings though which may be helpful.
Some of those sysctl settings are useful; I know Whonix has a lot of them by default. Also, Whonix’s iptables rules are great for stopping some attacks the author mentions without having to mess with memory page size and other performance-related setting
I lol’d at his h4ck0rz stuff to