A post was merged into an existing topic: kernel recompilation for better hardening
Good point.
Here is a related bug report:
Summary:
- Ubuntu seems to harden this already.
Kees Cook (kees) wrote on 2011-04-25: #3
This mode change is “by design”. For local admins that what to relax this restriction, you can use dpkg-statoverride:
sudo dpkg-statoverride --add root root 0644 /boot/vmlinuz-$(uname -r) --update
To have this automatically happen with each new kernel, create /etc/kernel/postinst.d/statoverride:
.
#!/bin/sh
version="$1"
# passing the kernel version is required
[ -z "${version}" ] && exit 0
dpkg-statoverride --add root root 0644 /boot/vmlinuz-${version} --update
- breaks some KVM use cases
It is fairly common practice to boot kvm or qemu with something like:
kvm -kernel /boot/vmlinuz-$(uname -r)
- It might break simpler malware relying on this. It wouldn’t break more sophisticated malware - for that we couldn’t use a public kernel image - kernel would have to be (automatically) re-compiled at user’s machine (kernel recompilation for better hardening) ([+ have different entry / kernel symbol locations, of course. If we’re unlucky, the user would reproducible compile the very same kernel?].
Richard W.M. Jones (rich-annexia) wrote on 2011-04-26: #5
What is being protected by this mode change? This kernel is distributed
on hundreds of mirrors – there is no secret in here.
Kees Cook (kees) wrote on 2011-04-26: Re: [Bug 759725] Re: The kernel is no longer readable by non-root users
The mode changes do not protect a system from any dedicated attacker (for
the reason you state), but it does have real-world benefits against
simplistic kernel exploitation (keeping kernel symbols away from non-root
users). It is absolutely a trade-off.
Kees Cook (kees) wrote on 2011-04-26:
I am not saying they’re hidden from being looked up externally (just fetching the kernel package’s System.map file is easiest). But because the symbols can be extracted in the way you point out is why the kernel image itself needs to be unreadable. This change is to block the class of attacks carried out by script kiddies and automated systems that expect to be able to look up symbols locally and make exploits totally portable to all kernel versions. It changes the nature of future attacks, at least forcing attackers to take additional steps.
- might break guestmount / libguestfs
- might affect OpenStack
- might break tftpd serving /boot to netboot clients
- might break hobbit-plugins (whatever that is)
Richard W.M. Jones (rich-annexia) wrote on 2011-04-26: #8
By the way, I myself actually wrote code that walks through the kernel memory
finding the location of the symbols. You’re not gaining any extra security by
making this change, but you are making Ubuntu less useful.annexia.org >> repositories - virt-mem.git/blob - lib/virt_mem_kallsyms.ml
annexia.org >> repositories - virt-mem.git/blob - lib/virt_mem_ksyms.ml
- ^ → User should not have access to
/proc/kallsymstoo? Doable? Any side effects? Then we can protect from above enumeration too.
I would go as far as saying that non-root users by default shouldn’t be able to read any file in /boot? Let’s use dpkg-statoverwrite or something to restrict access so only members of linux group boot can read it?
-
create linux group
boot(or similarly named?) → Port to sysusers.d mechanism?
sudo chgrp --recursive boot /boot
sudo chmod --recursive o-r /boot
1 Like
Those only seem to be for the host so won’t apply to Whonix VMs.
Not needed. kernel.kptr_restrict=2 already fixes this exact issue. Run cat /proc/kallsyms and you’ll see all addresses have been replaced with 0000000000000000.
Making it unreadable won’t have any advantage.
I would agree with that.
1 Like
Yes. Could you implement this please?
1 Like
Hardening/Linux - Segfault and Hardening/Linux - Segfault (apparmor is probably a far better way to restrict access to /proc anyway as we can remove access for files entirely) look interesting.
I’ve been thinking of hardening file permissions for a while but don’t have many ideas except restricting /boot.
There is also more here Security - ArchWiki
1 Like
Where? Maybe https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/permission-lockdown or /etc/kernel/postinst.d? permission-lockdown can also be used for other file permission hardening.
Should be sufficient in the security-misc postinst script. If “others” aren’t allowed to read /boot and if only members of group “boot” and root can read /boot, I doesn’t have to be reapplied again and again. Could be protected by a do_once status file to allow easier customization (undo by sysadmin).
1 Like
If we must. If not avoidable through more efficient / appropriate solution. That script runs a lot. Could slow down performance. Would require multiple status _done files.
1 Like
Changing permissions wouldn’t slow down performance much.
We could do this instead:
if ! [ "$(stat -c %a /boot/)" = "700" ]; then
If you want it to be configurable, we can create a /etc/permission-lockdown.d folder for user configurations.
1 Like
The idea of the _done file to do this one once and then don’t bother the sysadmin with it anymore.
More error prone. This might work now (untested) but could break as distribution change things. Better to just run the commands to set the right permissions.
It’s already configurable though sudo pam-auth-update (then disable permission lockdown by security-misc) if someone ever asks about it. Not sure further configurability is required.
I don’t like https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/permission-lockdown much. It runs every time “sudo” runs or someone logins. Whenever pam is being invoked. Therefore spams systemd journal. Back then I didn’t have better ideas to implement it so permissions for existing users (those who upgrade) will be locked down.
My thinking maybe was: permission-lockdown cannot run only at postinst - since during build time, no /home/user folder exists. It is created during first login using pam mkhomedir.
Perhaps permission-lockdown could
- run at postinst to lockdown existing user’s home folders.
- And then pam mkhomedir with
umask=parameter could create new home folders (at first boot time) with already locked down permissions.
(locked down meaning: “others” cannot read. Not “world” readable.)
However, for purposes of locking down /boot, I think that is perfectly doable from security-misc postinst?
security-misc/security-misc.postinst at master · Kicksecure/security-misc · GitHub
1 Like
I meant allowing people to choose to disable/enable /home, /boot etc. restrictions (once they’re added) as they wish.
I would prefer to have something periodically check and restrict /boot in case the permissions get changed for whatever reason. If a user wants to have the permissions changed, they can disable permission-lockdown (or change specific settings like I said above).
1 Like
Since it’s only done once (and by the time they want to change the setting that setting is already turned on), it’s even easier for them to just change the permissions back to what they want. Thanks to the _done file, the sysadmin won’t be bothered with this ever again.
Why would anything package work on permissions on folder /boot directly? Or what else could change it?
Even if permissions for things inside folder /boot/something change (Debian deciding to change permissions for kernel image or something), that file would stay inaccessible since the root of the folder (i.e. /boot) already has the correct permissions.
If it should be something more periodic…More enforcing…
(Yet configureable. (?))
(And “non-opaque”.)
What about systemd’s /usr/lib/tmpfiles.d mechanism? Also looks quite appropriate?
(No, not just temp files. Yes, some files there configure permissions for persistent folders such as /var/log or /var/cache.)
Would that work?
1 Like
What if they don’t remember what the permissions were or aren’t technical enough to change them back to what they want?
I think it would be good to save the default permission and reset it if the user chooses too.
Just in case. E.g. a user’s mistake or misconfigured script can do that.
You wouldn’t want accidental read-write access to kernel images.
Permissions may be more likely to change for other folders we might restrict in the future.
That looks great actually. Seems like a far better approach.
1 Like
OpenSUSE actually has a package that changes the file permissions.
https://en.opensuse.org/openSUSE:Security_Documentation
- the easy profile has a focus on ease of use where more program features work out of the box without the user having to intervene. It also means that there is a larger security attack surface. It can be used for typical single user desktop systems when usability is favored over stricter security.
- the secure profile is more security oriented and disables certain program privileges. This can result in some program features not being available or behaving less conventiently. It can be used for typical server or multi-user host machines.
- the paranoid profile is a tightly locked down set of settings that isn’t fully usable in production, because a lot of program features will stop working. This should only be used when security is the major requirement and when you are willing to tune the profile into a state where you can perform the task you want to fullfill with the system.
I can’t find the permissions file anywhere online to see what they do. I’ll setup a VM to check.
1 Like
Here is opensuse’s configuration.
permissions.secure: Debian paste error
permissions.paranoid: Debian paste error
2 Likes
Awesome find! Can you find the source code? Maybe it can be ported to Debian.
Looks like “/etc/permissions.paranoid” was forgotten. Most search results from year 2002 - 2004. Looks like we’re rediscovering old security knowledge.
1 Like
The source only seems to be distributed in .rpm files which I have no idea how to use.
No, it’s still supported by opensuse. Just doesn’t seem very popular.
1 Like
An rpm is similar to a deb. Just an archive with a different file extension. Please open it and look around.
ark permissions-20180125-lp150.1.2.src.rpm
permission.spec
License: GPL-2.0+
Url: GitHub - openSUSE/permissions
source code repository is here:
1 Like
Are there any other kernel modules that we could load for better security?
1 Like