Benefiting from security-misc inside Qubes-Whonix.

Patrick · January 3, 2024, 2:18pm

I am certainly interested in sudo hardening.
(Multiple Boot Modes for Better Security: an Implementation of Untrusted Root)

So any patches are appreciated. If it’s only mostly done and a few remaining issues, I can certainly try looking into any remaining breakage.

hidepid breaks pkexec. That’s a pkexec upstream issue. I certainly won’t find a solution for that. Reference might be here somewhere:

github.com/Kicksecure/security-misc

Hide Proc | New Approach

opened 07:51PM - 19 Nov 23 UTC

closed 03:30PM - 23 Nov 23 UTC

monsieuremre

>An optional systemd service mounts /proc with hidepid=2 at boot to prevent user…s from seeing another user's processes. This is >disabled by default because it is incompatible with pkexec. It can be enabled by executing systemctl enable proc-hidepid.service as root. This not only breaks pkexec but breaks a lot of other thing as well and requires manually adding some services into groups that are exepmted from the policy. What we should do is, instead of ```hidepid=2```, we set ```hidepid=4```. > hidepid=ptraceable or hidepid=4 means that procfs should only contain /proc/<pid>/ directories that the caller can ptrace. So basically root processes can access other users stuff, because they can ptrace the processes anyway. But non privileged users/processes are limited. This is a massive improvement from not hiding anything. I did some little testing on Debian on Gnome Wayland and it does not seem to break anything, for now. I suggest we go with this option. massive leap without breakage. This option is also somewhat new. There used to be only 0, 1 and 2. 4 seems to be added recently (in a relative sense). We would need no service for this. We could just remount it the good old way in the secure remount thing. I can add this to the branch, that might get merged as the new secure mounting solution.

That is expected because it’s enabled by default nowadays.

I am not sure what future that approach has.

Tons of approaches, discussions.

In essence: the new idea is to ship a hardened /etc/fstab.

file needs more work: security-misc/usr/share/doc/security-misc/fstab-vm at master · Kicksecure/security-misc · GitHub

For Qubes you could contribute fstab hardening directly to Qubes, starting here:

github.com/QubesOS/qubes-issues

mount /tmp /var/tmp /dev/shm with nodev nosuid

opened 11:29AM - 18 Sep 19 UTC

adrelanos

T: enhancement C: templates security P: default

These folders * /tmp * /var/tmp * /dev/shm are user writable. Similar… to * https://github.com/QubesOS/qubes-issues/issues/5263 * https://github.com/tasket/Qubes-VM-hardening/issues/41 [Quote](https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132) Joanna (founder of Qubes OS): > I've been recently talking about this with Solar Designer of Openwall (a person who probably knows more about Linux security model than most of us together) [Quote](https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301320361 ) solar: > Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.) Therefore I concluded: SUID has to go away. At least user (speak: possibly malware) created SUID should be prevented form being easily executed. [Getting rid of SUID binaries which are installed by default is worthwhile too but less trivial.](https://forums.whonix.org/t/disable-suid-binaries/7706) Therefore out of scope for this ticket.

Does pkexec work?

This might be outdated. This is evidenced by the discussion and the ticket still being open:

github.com/QubesOS/qubes-issues

Automate vm sudo authorization setup

opened 02:28AM - 12 Mar 17 UTC

tasket

T: enhancement C: core P: major

#### Qubes OS version (e.g., `R3.2`): R3.2 #### Affected TemplateVMs (e.g., …`fedora-23`, if applicable): All Linux --- ### General notes: Users wishing to enable dom0 prompts for domU sudo authorization must edit several config files according to doc/vm-sudo... https://www.qubes-os.org/doc/vm-sudo/ Since this configuration has worked well for many months with only one (fixable) sticking point, I figured the setup could be automated with a script provided by Qubes. This would allow the user to choose the sudo mode without being mired in the technical configuration process. --- #### Related issues: #2693

File /etc/sudoers.d/qubes already had this comment removed. Website is probably also outdated. Reported just now.

github.com/QubesOS/qubes-issues

Qubes vm-sudo documentation write-up against sudo passwords inside App Qubes outdated

opened 02:17PM - 03 Jan 24 UTC

adrelanos

T: bug C: doc P: default pr submitted

https://www.qubes-os.org/doc/vm-sudo/ is outdated. The comment ``` # WTF?…! Have you lost your mind?! # # In Qubes VMs there is no point in isolating the root account from # the user account. ``` This is evidenced by file `/etc/sudoers.d/qubes` which previously had this comment, having nowadays this comment removed. That write-up was just a copy of `/etc/sudoers.d/qubes`. Already in 2017, Joanna upgraded her viewpoint, see: https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132 This ticket is still open, which means Qubes would be open if the community would implement this.