What I mean is live mode with a folder shared through the VM, that would behave like Tails with a persistent volume. The data is just data and should not be automatically processed by anything, noexec is just to help prevent accidents. There should be clear separation between trusted user data (immutable) and untrusted user data (shared folder). I don’t think this requires anything from Whonix. Sorry I’m having a hard time sticking to a thread.
Live mode does not disable shared folders, is that something you’re thinking of? How does live mode work with another virtual drive /dev/sdb etc?
Are you talking about separate grub entries for each mode or flags that can be added to the kernel command line?
With custom entries you could e.g. blacklist vboxguest in persistent mode. But it sounds like live mode is not technically binding so it would be up to the host to ensure shared folder is not accessible while system disk is writable.
Perhaps an option on the grub line to disable root?
Related: is it possible to start a VM with a given grub entry?
Live mode currently does not disable virtual machine shared folders.
Added to comparison table here:
And asked about it here just now:
Agreed. Data in virtual machine shared folder shouldn’t be processed by default. This is already the case. I wouldn’t know what would process it.
noexec for shared folder is a good idea. It is already noted here: (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?
They’re not automatically mounted. A root user or malware with root rights could mount these and write to it. This is illustrated in the comparison table here: grub-live: Boot existing Host Operating System or VM into Live Mode
This could be parially taken care of (root user) by booting into non-root mode (this forum thread). A root exploit can always undo that though.
Yes, that’s the idea.
Indeed. Good point. Yes, this should be documented.
[A] Also when work on Whonix Host progressed, we could add a starter/script which will help the user with such configurations for better usability.
That’s what this very forum thread is for. Help welcome.
Possibly yes. Both, VirtualBox and KVM support serial console.
Once we have that working, this might be automated with a script. Related to [A].
There is hopefully no execution going on but certainly some processing/parsing. Otherwise you would not see the mounted folder or its contents nor the attached device.
Once there is plan, this might be available as a package quickly within a day or two or so. Planning on implementing this soonish.
How would I technically implement a no-root boot mode?
Idea 1)
- at early boot time
- use a systemd unit file
- if a certain kernel boot parameter such as
nosudo=1is set - run as root:
delgroup user sudo
- Otherwise if a certain kernel boot parameter such as
sudo=1is set- run as root:
addgroup user sudo - That seems a bit weird, insecure for those who already followed instructions Prevent Malware from Sniffing the Root Password. Those users wouldn’t want their user
useraccount be added to groupsudobehind their back.
- run as root:
Therefore perhaps the default should be swapped.
Idea 2)
- New builds of Whonix come without any user account added to the group
sudoby default. - How to handle existing users that upgrade? Removal of user from group
sudomight be a bit intrusive? - If a certain kernel boot parameter such as
nosudo=1is set:- run as root:
delgroup user sudo
- run as root:
- If a certain kernel boot parameter such as
sudo=1is set:- run as root:
addgroup user sudo
- run as root:
Might also clash with security-misc since security-misc will abort to install if there are no users in group sudo.
security-misc/security-misc.preinst at master · Kicksecure/security-misc · GitHub
We probably shouldn’t break root login for ssh (for server support, Kicksecure, non-Whonix).
(Already done: For security reasons the root account is locked and expired by default in Whonix ™ 15.0.0.3.6 and above.)
Most users seem to prefer security anyway.
Maybe make another poll specifically about root.
Root login via ssh should be disabled either way. Allowing someone to remotely login as root isn’t a good idea.
That was about security vs customization. Also that was a really abstract questions. If users really understand what’s at stake, they might decide otherwise.
This is not so much customization. This is more about security vs inconvenience.
This is more about security vs stability / bad surprises. Upgrade → cannot use “sudo” anymore. Terminal-only users couldn’t even run “sudo reboot”.
Maybe. Well, Whonix / Kicksecure don’t come with openssh-server installed by default. OpenSSH root login allowed by default or not setting doesn’t change much. Should change anyhow? How? Modify files in /etc/ssh? There is no configuration snippet drop-in folder (“.d”). Seems really intrusive → dpkg interactive conflict resolution dialog
( Configuration Files - Kicksecure )
Users who have openssh-server installed and then install security-misc or some other package are a different case.
We had a case we didn’t foresee a case where a user got locked out from his own server: Is security-misc suitable for hardening bridges and relays? - #4 by minimal
We’re already locking su. (Restrict root access)
Some users don’t use sudo. Maybe we should tell them they should. Maybe sane to require that.
Now we’re considering to remove user user from group sudo through an upgrade.
I am not saying we shouldn’t do it. Just thinking it all through aloud.
How much security would we gain from that anyhow? Let’s assume most times users boot into user user with sudo disabled. Ok… Let’s say their user account gets comprised through a remote exploit. That malware would have a harder time to break out since no easy escalation to root level, kernel level. Let’s say the malware starts itself through ~/.bashsrc or any of the many dotfiles. Then the user wants to upgrade and reboots in sudo=1 mode. The user now enters its user user password and gains root rights by using sudo. Boom. Malware can hijack that / sniff the password and become root too. We don’t get that much security from that?
How do we prevent that? Rely on VirusForget? 1) doesn’t exist. 2) not sure it will be finished 3) not that great, might be holes, not sure yet.
Instead, I am re-thinking about the old idea of user admin as per this very post: Restrict root access - #14 by Patrick.
Yes, once the plan is getting more specific, this will be a good idea. (Specifically if going the user admin route.)
Whonix comes preconfigured so root isn’t really needed for the average user for anything other than customization or debugging.
apt-get-update-plus has a sudoers exception for that.
There’s no need to use sudo for that anyway. Unprivileged users can still run /sbin/reboot. The only issue is that /sbin isn’t part of $PATH by default (an alias can be added for reboot if needed).
Best option seems to be using str_replace on the openssh config file. It’s a bit hacky but better than just replacing the entire file.
I don’t use ssh much so I don’t know if there’s any better option.
Or, just not include it in security-misc since Whonix doesn’t have ssh anyway. We can leave configuring specific applications to be the user’s job.
We can add a warning to sudo mode and inform the user of the consequences of what they’re doing.
Restricting sudo is a security advantage. The only problem is if the user messes it up themselves which isn’t really on us.
Having boot modes
-
nosudo=1→delgroup user sudo -
sudo=1→addgroup user sudo
wouldn’t improve security too much. At least wouldn’t help much for users who install some custom package every now and then. (They need to use sudo for that.) Let alone add custom (third party) APT sources list. (Requires root to edit sources.list.d.)
Mostly would help users who do follow Prevent Malware from Sniffing the Root Password.
(But these would not even want addgroup user sudo.)
Not sure it’s even worth it to implement boot modes nosudo=1 / sudo=1?
(Just called nosudo=1 / sudo=1 for discussion. Would be presented to user in better terminology.)
Comparison with Tails:
Tails boots always fresh, malware clean. Considered non-compromised.
(Just assuming it for sake of discussion not considering firmware trojans etc. When boot from read-only media boot.)
Tails boots by default without root access. Setting a root password is an opt-in. Tails an edge here.
There are kinda two paths there.
- [1] Allowing more and more things (apt dist-upgrade, install packages from packages.debian.org) without need to gain root / entering sudo password. Android does that. Users can do a lot things there without root. For example, setting up VPNs.
- [2] Make users boot into user
admin.
These two are not really exclusive. [1] will always be limited. A lot effort to implement. Might never get there.
I typed too little. I meant, after users just run “sudo apt-get dist-upgrade” or “upgrade-nonroot” they can no longer use “sudo”. Kinda unexpected, breaking usability change. Considered unstable by users most likely.
That would mean “boot into user admin” is an OK solution too?
Sounds good.
Yes. However, it’s on us to provide easy, secure work flows. I think “boot into user admin” is a nice clear way to separate things. Will describe more clearly soon.
An alternative solution would be to add removing the sudo group to the hardening guides instead of making boot modes.
I don’t like the sound of that too much. Android is really different from Debian. If we allow unprivileged users to install packages, an attacker can install whatever they want from the repos to add attack surface.
e.g. 1: attacker installs package with setuid binary → exploits vulnerability → gains priv esc.
e.g. 2: attacker installs kernel module from the repos which adds kernel attack surface → exploits vulnerability in new module.
Meanwhile android apps cannot add any new kernel attack surface or increase the chances of priv esc. All apps are fully sandboxed, running as different users with strict SELinux policies and seccomp filters. It isn’t really comparable.
The admin user is better but not the best. An attacker can still login as the admin user too.
Btw by “boot” do you mean “login” (as a user called “admin” with sudo privileges) or are you talking about a boot mode? I assume you meant “login”.
The Separate User "admin" Plan.
- Add a new user
admin. - User
usernot being member of groupsudo/suetc. - Root login stays disabled. (Already done.) (Restrict root access)
- To gain root rights:
- Users are advised to login as user
adminand then usesudoas documented on Prevent Malware from Sniffing the Root Password, OR - Boot into “sudo mode”.
- Users are advised to login as user
- No (good) password for user
userrequired. (Except, if SSH login is permitted.) - Good password only required for user
admin.
Boot into “sudo mode” meaning:
If users choose “sudo mode” in grub boot menu, the system would boot and login the user into user admin rather than user user. User admin would have root. After users are done, these are advised to reboot to continue using user user.
(And those who don’t like it could continue using user admin (bad) or sudo addgroup user sudo (slightly less bad).) [1])
Not sure the cumbersomeness usability wise is acceptable. Could poll about that. Could also poll about various alternatives.
[1] Using user user is an anonymity feature. → GitHub - Kicksecure/dist-base-files: base files for distributions - several important miscellaneous files, such as /etc/hostname, /etc/hosts, /var/lib/dbus/machine-id and more
How? An attacker (let’s say some compromised user account) cannot use su since not member of group sudo. Well, could try to bruteforce the password of user admin? That may be possible until we can port to wayland.
Agreed.
Bruteforcing the password is what I had in mind. Unless we set strong password requirements (see pam_cracklib), an attacker can attempt to login to the admin account and bruteforce the password.
No strong password required fortunately for linux user login. Bruteforcing into linux user accounts is already severely limited. Elsewhere. Summary written here just now:
A post was merged into an existing topic: How strong do linux user account passwords have to be when using Full Disk Encryption (FDE) too?
Name for admin user?
adm or admin
?
admin is best IMO unless it can conflict with some other program out there(?)
There is a group adm.
May not be a good idea to use adm as a user name? standard user accounts - uucp,gopher,adm, nobody... - what are they, why are they there, when shall they be used? - Red Hat Customer Portal lists user adm for nologin. That could potentially cause some issues. (Even if not a Debian thing I like to keep things potentially open to be ported by someone to another Linux distribution.)
Talking about VMs here…
Under the The Separate User "admin" Plan. (grub boot menu to login into user user or user admin):
- Could we even go for autologin in X
andvirtual console for useruserwhen booting into user-only (non-root) mode?- In this mode, user
adminstays password locked by default.
- In this mode, user
- Could we even go for autologin in X
andvirtual console for useradminwhen booting into superuser mode?- In this mode, user
userstays password locked by default.
- In this mode, user
- Could we even go for passwordless sudo for user
adminwhen booting into superuser mode? - All passwords locked by default.
- No more default passwords for user
userand no default password for useradmin. - Still no root login.
implementation goals:
secure auto login + secure passwordless sudo + uncrackable user passwords
By using locked passwords by default, there wouldn’t be any passwords that adversaries could crack.
Could the use of autologin be abused by non-autologin, limited user accounts such as user web? Could for example a compromised linux user account web take advantage of user user being autologin? I wouldn’t know. Maybe different for graphical applications running under a different user account? But then probably X is too broken to consider this anyhow.
Would an auto logged in virtual console offer any attack surface for compromised non-user user accounts such as user web?
Users will always be able to configure what they want. (Such as the current behavior of only user user and ability to use sudo.) In this post I am trying to find a design for the default which works good enough for most users.
admin. adm is already a group and would likely cause conflicts. admin may be too generic though and might also cause conflicts. Maybe “sysadmin”?
Also wondering what the right package (or package name) for this would be. It interacts with grub-live, maybe apparmor-profile-everything (superroot) and is Kicksecure / Whonix specific (?).
Grub default boot menu entries:
PERSISTENT mode USER (For daily activities.)LIVE mode USER (For daily activities.)PERSISTENT mode ADMIN (For software installation.)PERSISTENT mode SUPERADMIN (Be very cautious!)Recovery PERSISTENT mode SUPERADMIN (Be very cautious!)
Boot modes considered too unimportant to be added to grub default boot menu:
LIVE mode ADMINLIVE mode SUPERADMINRecovery LIVE mode SUPERADMIN
I don’t see good use cases for these. But could be convinced otherwise with user feedback.
If anyone cares about these, there could be files in /etc/grub.d/ folder that add such entries but these files could be non-executable by default. Thereby update-grub would ignore them. To opt-in into such modes, users could just run sudo chmod +x /etc/grub.d/somenumber_name-of-boot-mode.
Also users who really want something special/custom would be able to add whatever they want to /etc/grub.d/ folder / grub boot menu.
Also by using grub boot menu editing (key e) at grub boot menu, kernel parameters can be adjusted and any combination would be possible.
Use cases for the different modes:
-
PERSISTENT mode USER (For daily activities.): Useful for browsing, e-mail, chat, etc. or just letting an already set up and installed server run. Even upgrading throughupgrade-nonroot. -
LIVE mode USER (For daily activities.): Same as above but without persistence. -
PERSISTENT mode ADMIN (For software installation.): users could runsudo apt install whatever-software-package, then reboot into USER. Editing/etc/apt/sources.list.damong many other things prohibited for better security. -
PERSISTENT mode SUPERADMIN (Be very cautious!): users could add foreign sources to/etc/apt/sources.list.dor do anything (full freedom), then (optional but advisable) reboot to ADMIN mode, install packages from third party repositories. -
Recovery PERSISTENT mode SUPERADMIN (Be very cautious!): The usual recovery mode.
Anti-opposition / “I want the old Whonix back”:
Users who don’t like (any, multiple or all) of the new options…
-
PERSISTENT mode USER (For daily activities.)[A] -
LIVE mode USER (For daily activities.)[B] -
PERSISTENT mode ADMIN (For software installation.)[C]
and who want “the old Whonix” “with unrestricted sudo” (PERSISTENT mode SUPERADMIN) back, who don’t want to see any of the new options [A], [B], [C]… These could just make these /etc/grub.d folder / grub menu entries gone by running sudo chmod -x /etc/grub.d/somenumber_name-of-boot-mode. (There could be a script to simplify that.)