Giving a linux-specific answer, I think SELinux (available in Red Hat like distros) or AppArmor (available in SUSE and ubuntu like distros) is exactly the thing you are looking for.
To quote wikipedia's AppArmor page:
AppArmor ("Application Armor") is a Linux kernel security module that allows the system administrator to restrict programs' capabilities ...
For further information, my use case is the following: a server that holds very sensitive personal information and messages and would be a potentially desirable target for attacks. In this case, is the "standard advice" enough?
I would rather say it's the minimum. But some of the advice is questionable though. Since you mention 'very sensitive personal ...
The answer is simple: no. You can do all sorts of things on your server to make it more secure, give less access et cetera, but at some point in time, there will be vulnerabilities. Regular system updates will protect you against them if you apply them very regular, but even then, they will always be a bit behind.
It means that you will need to create an ...
We had the same situation when installing our server cluster, to avoid such security issues our process was as following:
Set up switch with two port groups with different VLANs (internal, external)
Install nodes with the internal network only (1st NIC of servers)
Set up firewall rules to block all incoming traffic
Set up 2nd NIC of servers with respective ...
No. The question is not the number of open ports but which services are behind these ports and the security of these services. Thus, it is sufficient for an attacker if there is only one open port which one service but this service is exploitable.
I will explain how I understand this. Any application launched from under the current user has access to the keyboard, mouse, display (screenshot), and this is not good.
This is more or less true of all current operating systems. Any executable has access to everything the user it runs as has access to.
It is changing, with more sandboxing appearing. ...
No, that's not exploitable. Write permission on links is worthless in practice. To re-target a link, you need write permission on the parent directory. To modify the file or directory that the link is targeting, you need write permission on the target. Write permission on just the link lets you do neither of these things.
It is not uncommon especially for software for embedded systems (BusyBox etc) to have a single binary which has everything in it and then to hard link this binary to different names in order to provide the expected command names. This approach by itself is not a problem: while the different invocations of the binary will share read-only (or execute-only) ...
What you're able to see from the process running in the Docker container is a filtered view of the hosts /proc filesystem. It's somewhat less than what any process running on the host could see.
on Q1 Whether this is a security breach depends very much on the environment you're operating in. For most environments, this isn't likely to be an issue, you ...
The cipher-name in your example is not '@'. The field you're looking at is actually the hdr_size field.
The mistake you've made is trying to decode a LUKS2 container with LUKS1 encoding. In the table provided, you've shown that the second field (bytes 6-8) are the version data field. And your hexdump clearly shows that the first LUKS container (luksVol1) ...
There are two copies of the header data, not just the JSON but also the preceding binary header. This is very common in storage formats. The reason is resilience against failures while writing the header data, for example a power loss. If updating one of the copies of the header fails, the other copy is still valid. When the driver mounts the volume, it ...
I see this question was posted in Nov 2016, but LUKS2 (released in 2018) added the ability to have keyslots stored on a distinct device than the encrypted volume's device.
If you do this, then a FDE drive can be setup so it contains no plaintext metadata and the drive's entire contents is indistinguishable from random bits.
Of course you'd still need to ...
If you run the WordPress as user www-data, an attacker can do everything the user www-data can do. That's usually quite a lot:
Wide read access. You could test what you can access e.g. using sudo su -s /bin/bash www-data.
Write access to all the other sites run as www-data. You should treat every site as potentially compromised.
To prevent that in the ...
In general, hidepid mentioned in the comments is the best way.
If you need more security than that, use a mandatory access control system like SELinux or AppArmor, and possibly systrace. These tools let you restrict file system access, syscalls and more. I think most of the info in /proc is not available from syscalls, but I'm not up-to-date on this.
It looks like the best option is to use a custom seccomp profile
You can see an example here
Other links to the file you need in case they disappear:
Protecting memory from the host is going to be the tricky part.
To demonstrate this, I have this system lying around:
Host: Ubuntu 18.04.4 LTS
Virtualization stack: VirtualBox 5.2.34
Guest: Kali linux 2018.3
In Kali, I opened a text editor and typed the text "SecretForcn271828n", but I did not save it to disk, it's just in ...
The tool I was looking for is called "msktutil", by Dan Perry and others (https://github.com/msktutil/msktutil). It can create the keytabs I was looking for (COMPUTER$@DOMAIN.EXAMPLE>COM). A man page (Ubuntu) is here: https://manpages.ubuntu.com/manpages/eoan/man1/msktutil.1.html
It's a useful tool when you want to script docker images/containers that ...