Which package should the whonix-shell-script profile be in?
I think we should remove the apparmor profiles in security-misc and add whonix-shell-script to apparmor-profile-everything.
Can these all be in apparmor-profile-everything?
apparmor-profile-anomdist abstractions/base longer requires modification?
Then yes. All in apparmor-profile-everything.
Alternatively:
The abstraction: apparmor-profile-anondist.
The profiles: wherever the corresponding scripts reside.
Not whonix-shell-script. kicksecure-shell-script.
Trying to view this from perspective of third parties and customization. Allowing them to pull packages without unnecessary dependencies.
Yes.
Why wouldn’t it?
There is only one profile that lists each script and there isn’t much point in splitting up 11 lines into 4 profiles.
madaidan via Whonix Forum:
Merged.
Should also read access to all of /boot/* be prevented?
initrd containing anything sensitive? /boot/grub/grub.cfg worth being
protected? /boot/config* sensitive? Anything else in /boot?
It’s not allowed in the init-systemd profile anyway. That pull request was mainly about hiding other files like /lib/modules/*/build/System.map and not necessarily ones in /boot.
Not that I’m aware of.
Write access? Yes.
Read access? Not much.
It can give an attacker a better idea of how the kernel is configured but hiding it would probably give a negligible gain, if any at all.
I’d say lets remove it. Access to /boot/config* (kernel config), /boot/grub/grub.cfg (grub config) (i.e. all of /boot since we are at it, for consistency) as well as /proc/cmdline (among as much as sanely possible from /proc and /sys generally). The goal here would be to have (user or root) malware run “in a vacuum”. Most applications would be able to run just fine “in a vacuum” but malware trying “weird” things could gather as little information (kernel config, kernel hardening settings, kernel pointer addresses) as possible to prevent it escalating from user->root or root->kernel.
Removing access to /proc/cmdline would break live mode indicator but perhaps live mode can be detected through some other way.
If apparmor-profile-everything already prevents reading kernel images (⚓ T943 make /boot and /lib/modules unreadable even for root) would it be worth to additionally remove read file system permission (chmod o-r) for kernel images (⚓ T937 make /boot and /lib/modules unreadable for non-root users) or would that be overkill? Maybe additionally adding the latter would be cleaner? Then those who want to read the kernel image for legitimate reasons (KVM kernel boot; security audit of our kernel, …) would easier see why that is failing? They’d try to read the kernel image as non-root user - that works for most distributions. That would fail since blocked by file permissions. Easy to see. Then they’d try again as root which would also fail which would not be obvious that it’s apparmor-profile-everything blocking that.
Maybe with something similar to https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/remove-system.map?
/proc/cmdline is used a lot and isn’t that dangerous.
There is already very little allowed.
Yes, I think we should do both. Those can be restricted to root with permission-hardening e.g. https://github.com/Whonix/security-misc/blob/master/etc/permission-hardening.conf#L9
I’m brainstorming ideas on how kernel information can be found.
We should remove access to all bootloader files like /**/grub/ and /**/grub.d/. Currently, write access is denied to those directories but this should be further restricted so an attacker can’t learn about any hardening parameters.
All sysctl access should also be denied. This means denying access to /**/sysctl.d/ and /proc/sys/. This would prevent attackers from learning about our stricter sysctl values and prevent them from changing sysctls to worsen security. I’ve been planning to do this for a while but we first need to create a profile for systemd-sysctl so sysctl still works for us.
If we feel like disrupting kernel debugging, we can remove access to the kernel logs by denying access to /proc/kmsg and /dev/ksmg. We can also remove the CAP_SYSLOG capability as dmesg_restrict restricts dmesg to CAP_SYSLOG but that may be too disruptive.
All apparmor information can be denied too such as /sys/kernel/security/apparmor/ and /sys/module/apparmor/. But, this will make it impossible for us to detect if apparmor is enabled or exactly what profiles are in use. Or, we can remove all /sys/kernel/ and /sys/module/ access entirely as they might contain some important kernel info.
/proc/modules should go as it allows an attacker to see which modules are currently loaded. apparmor-profile-everything restricts this to root already but we can restrict it further. This will break lsmod and other things.
/lib/modules/ and /usr/src/ should go.
Maybe /etc/kernel/ and /etc/os-release should go.
uname can also find kernel versions and other things. uname is its own syscall and doesn’t get info from a file so this probably can’t be solved with apparmor.
If you run sudo ps aux, you can see some kernel processes (the ones enclosed in square brackets). Looking at an strace of ps aux, some kernel processes have their own /proc entries.
I can’t find a way to hide kernel processes from userspace entirely, although, we can remove the CAP_SYS_PTRACE capability so hidepid=2 will hide other processes from root which might include kernel processes. We should also deny access to /etc/fstab and other mount perms so root cannot undo this.
Sounds really good overall.
Very good.
It makes it hard to debug the system. Even for developers. How would I know when booting with apparmor-profile-everything that lkrg and tirdad are properly loaded? Disabling apparmor-profile-everything and then looking isn’t an option since this isn’t an equal test. It might be OK while apparmor-profile-everything is disabled but invisibly failing without ability to diagnose while apparmor-profile-everything is running.
Likely there is a solution for this. Didn’t grsecurity have a concept of gadm, grand admin, super root or something?
Can we add a linux user account and/or tool to become a fully unrestricted super root capability shell? Could be running under user superadmin but when superadmin uses sudo or uses su it would be “full” (traditional) root access. Such a user account could be locked by default. Enabling it could be done by booting into recovery mode from grub boot menu.
Implementation? Maybe another apparmor profile which restricts nothing for some process/user. But only superadmin allowed to execute that process. And execute, user authentication (password) needs to be successful. No default password. Locked by default. Enable through recovery mode. Maybe another case for pam_apparmor? Could we use pam_apparmor to allow superadmin to use an unrestricted apparmor profile or to run unrestricted?
pam_apparmor packaging / PAM integration done but no user profiles added.
- pam_apparmor integration · Kicksecure/apparmor-profile-everything@b8eeed4 · GitHub
- apparmor-profile-everything/usr/share/pam-configs/apparmor-profile-everything at master · Kicksecure/apparmor-profile-everything · GitHub
sudo apt install libpam-apparmor
(Already a dependency of apparmor-profile-everything.)
Not default yet. Can swap Default: no to Default: yes for package apparmor-profile-everything whenever you consider it good enough.
To enable/disable, interactive (this is what users could use):
sudo pam-auth-update
To enable/disable, in scripts:
sudo pam-auth-update --enable apparmor-profile-everything
For now using optional.
optional pam_apparmor.so debug
Quote Pam_apparmor · Wiki · AppArmor / apparmor · GitLab
If you make the pam_apparmor module ‘required’ instead of ‘optional’, the session will abort if pam_apparmor is not able to successfully find a hat to change_hat into. Be careful when making it required; it is possible to cause all attempted logins to the service to fail if the apparmor policy is insufficient.
We can change to required whenever you think it’s good enough.
It will add an entry to file /etc/pam.d/common-session but it could also be made /etc/pam.d/common-session-noninteractive.
Please see file /etc/pam.d/common-session.
cat /etc/pam.d/common-session
At which position do you want pam_apparmor?
Quote Pam_apparmor · Wiki · AppArmor / apparmor · GitLab
Likely you will to want add the pam_apparmor module after other
session management modules.
Which I understand as “low priority” which results in “all the way down, last pam module to process”. This is what is implemented now. Speculation: By loading pam_apparmor earlier, let’s say before pam_systemd.so you might have to add all the apparmor profile rules that pam_systemd.so requires which is unwanted for a more restricted user profile.
Maybe have a look at folder /usr/share/pam-configs.
Maybe compare /etc/pam.d folder before and after enabling apparmor-profile-everything to see how it changes.
PAM integration based on this:
https://wiki.ubuntu.com/PAMConfigFrameworkSpec
We can add something like a debug boot mode. Android does something similar where a lot of debugging functionality is not included in default user builds but are available in userdebug builds.
I think you mean gradm. That was just the tool to parse the policies.
https://en.wikibooks.org/wiki/Grsecurity/The_Administration_Utility
That would add far too large attack surface that I’m not really comfortable with. A debug boot mode or similar like I’ve described above would be a far better approach.
The bottom as per the wiki.
Following the pam_apparmor example, only /bin/su is being confined. I think I might need to confine more things in /etc/apparmor.d/pam_binaries but I don’t know what to confine. What program starts the user’s session?
madaidan via Whonix Forum:
What program starts the user’s session?
Everything in /etc/pam.d folder (except shared files such as
common-session which are imported by others for “code sharing”) can
start a session.
I meant a program. So I can confine it which would hopefully confine everything else in the user’s session (like how confining init confines the whole system).
There might be no single program which can start user sessions. There are probably many programs that start sessions. For that, I had a look here…
ls /etc/pam.d/
Here is a limited selection:
/etc/pam.d/cron
/etc/pam.d/su
/etc/pam.d/login
/etc/pam.d/sudo
/etc/pam.d/lightdm
These pam file names can be used to deduct which programs can start user sessions. Among these are cron, su, login, sudo and lightdm.
madaidan via Whonix Forum:
We can add something like a debug boot mode.
Alright. And how would that debug mode boot mode work?
The debug mode needs to be somewhat close to a non-debug boot. Otherwise
it doesn’t make a fair comparison. apparmor-profile-everything needs to
be active during debug mode boot. Then how could any kernel boot
parameter result in the ability to open a superroot shell?
If a specific kernel boot parameter is set, allow some application
(terminal emulator) to run apparmor unconfined. Otherwise not.
If a specific kernel boot parameter is set, copy some apparmor profile
which allows some some application (terminal emulator) to run apparmor
unconfined. Otherwise, rm -f /path/to/debug-shell-profile.
Then apparmor-profile-everything would have to protect tampering with
/proc/cmdline (writing to, mounting over with malicious version,
deletion, symlinking with something else).
The bottom as per the wiki.
Alright, perfect. So current pam file priority stay as is at 0 (lowest
priority).