There is no ‘on’ option for amd_iommu. Is there some way to check if these settings are valid/recognized without testing them? Maybe someone familiar with the kernel on Debian bug tracker?
2 Likes
Weird. The Arch Wiki and a few other places say to use amd_iommu=on. Maybe the kernel docs are wrong?
2 Likes
Well I’m not going to argue with Arch documentation 
2 Likes
The System.map files should be removed. By default, /boot/System.map-* contains kernel symbols which could be useful to an attacker. Setting kernel.kptr_restrict=2 hides these from /proc/kallsyms but an attacker can just look at the System.map files to get the symbols anyway.
These could possibly be purged during the build or at boot with a systemd service.
Tails also removes these.
System.map files are only used for debugging or malware.
It may be useful to disable the SysRq key too. It allows anyone to use certain commands that the kernel will do regardless of what it’s currently doing. It can be disabled with sysctl using kernel.sysrq=0. I am not too sure about this one though.
See QA/Sysrq - Fedora Project Wiki. It doesn’t look too good.
2 Likes
Sounds all great!
Could you please add a script to:
https://github.com/Whonix/security-misc/tree/master/usr/lib/security-misc
The deletion logic should be in the script not in a systemd unit file directly. Reason:
- can call that script from a systemd unit file, as well as
- can call that script from https://github.com/Whonix/whonix-initializer/blob/master/usr/lib/anon-dist/chroot-scripts-post.d/80_cleanup#L416 so it can be done inside chroot too (decreases image size a bit)
- I might add “
source /usr/lib/helper-scripts/pre.bsh” (if existing) so this can even be controlled by settings drop-in files.
2 Likes
comment added here:
Remove System.map and restrict the SysRq key. by madaidan · Pull Request #13 · Kicksecure/security-misc · GitHub
2 Likes
1 Like
A post was split to a new topic: lynis - security auditing tool for Unix based systems
Back to hidepid.
I would not hold my breath for [feature request] /etc/fstab.d · Issue #790 · util-linux/util-linux · GitHub to materialize. The ticket was not even reopened yet.
Let’s not touch /etc/fstab for stability reasons.
In /etc/fstab.d · Issue #12506 · systemd/systemd · GitHub poettering wrote [sniped by me]:
if I were you I’d just write a generator that looks at /etc/fstab and creates drop-ins for the .mount units systemd-fstab-generator generates that override the Option= line. i.e. let systemd-fstab-generator do its thing as it currently does (meaning: translating fstab into native systemd .mount unit files), but then have your own generator that tweak some of these mount units with additional generated drop-ins as you need.
Can you make head or tail of it?
We don’t have to make it as complicated as having our own generator. Hardcoding the few option we need in drop-in config files would suffice.
Btw there are files in /run/systemd/generator/ which are # Automatically generated by systemd-fstab-generator if that helps.
Alternatively we had:
theory #1:
theory #2:
theory #3:
Could you work on this please?
1 Like
It sounds very complicated and hard to do.
Those seem to be systemd .mount files. I think systemd generates .mount files out of /etc/fstab and uses them to mount the filesystems.
I can try. The past attempts didn’t work though.
1 Like
Mounting /proc with .mount files doesn’t seem possible.
host systemd[1]: proc.mount: Cannot create mount unit for API file system /proc. Refusing.
Theory #1 seems to be the best solution right now. I’ll test it now.
1 Like
Theory #1 works great! Create a systemd service with:
[Unit]
Description=Mounts /proc with hidepid=2
Requires=local-fs.target
After=local-fs.target
[Service]
Type=oneshot
ExecStart=/bin/mount -o remount,nosuid,nodev,noexec,hidepid=2 /proc
[Install]
WantedBy=multi-user.target
I can add systemd sandboxing if needed (likely not).
1 Like
2 Likes
Should security-misc also disable coredumps? For distros that have them enabled by default.
It wouldn’t be needed on Whonix as Debian disables them by default and Whonix doesn’t re-enable them but it may be useful for other distros that are using security-misc.
1 Like
Awesome! Will test soon.
madaidan via Whonix Forum:
I can add systemd sandboxing if needed (likely not).
I am wondering if systemd sandboxing can do more harm than good here.
What’s the threat model? /proc containing at early boot something
malicious, which would upon using mount with remount options, result
in exploiting a vulnerability in mount, then leading to root compromise?
On the other hand, any (distribution) upgrade of kernel, mount or any
dependent libraries requiring any new seccomp could lead to remount fail
“in the middle”, hence end up with an unbootable system?
1 Like
madaidan via Whonix Forum:
Should security-misc also disable coredumps? For distros that have them enabled by default.
Yes, that would be good.
As per
security-misc will in future be available in Qubes Debian and Fedora
templates. Perhaps even in Qubes dom0. I.e. Fedora packaging upcoming.
And as per Whonix Packages for Debian Hosts and Whonix Host Enhancements
packages by Whonix can potentially be installed on any derivative of
Debian. If/when security-misc gets ever uploaded to packages.debian.org,
it will flow down to any derivative based on Debian.
1 Like
I just think we should sandbox as much as possible, especially root processes. A compromised systemd service could pretty easily be turned into a rootkit.
That’s unlikely as I doubt mount will be updated much and this is what testers versions are for. Any major kernel update will likely be part of the testers only version of Whonix. I could remove the syscall filter so it’d be even more unlikely for it to break.
Ok, I’ll add it now.
1 Like
1 Like
3 posts were split to a new topic: Should all kernel patches for CPU bugs be unconditionally enabled? Vs Performance vs Applicability