Please add to security-misc/debian/control at master · Kicksecure/security-misc · GitHub - readme is generated from that (sometimes, on script manual run).
1 Like
1 Like
1 Like
The text really helped. Well written. Applied a syntax fix on top.
1 Like
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
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