Set User Group restrictions: ROOT & Terminal

May someone help and/or provide links to resources to walk me through the easiest way to still enable the “group” known as “qubes” but then restricting both the Terminal access and the ability to SuDo into ROOT. I am trying to set up a non-admin user as a “daily driver” (to do word processing, connect USB drives for data storage and retrieval, check email, and surf the web). Such a daily driver user has no reason to access SuDo let alone ROOT, including no reason to drop down into a Terminal for CLI.

I have so far created a new user as well as a new “user group”, so now what do I do to that user group to restrict the user(s) within that “group”; and will such over-ride the “qubes” privileges whereby I still keep the “qubes” so the bar and templates load while it restricts from entering into SuDo and blocks Terminal and Terminal emulation from launching?

My issue is if I enable the “qubes” group to be added right now, it then allows the user to drop down into Terminal CLI as Sudo/ROOT. However, if I take the user out of the Use Group “qubes” then no top bar or Templates load!

Thus I am stuck …

However, I did find this:

I haven’t tried anything from that cited source yet, as it looks a little intimidating making me fretful that I might accidentally break something again that I will have to fix along with still trying to figure out how to do things like this.

Please advise :pray:t3:

I think you should look for a Qubes OS specific solution rather than a generic linux one. In the VMs, there is a package called qubes-core-agent-passwordless-root with an rather explicit name, so you can remove it from the AppVM’s template. And there is some threads on the forum and in the docs about other solutions:


Thank you for pointing me in a direction!

I will look over the resources you linked to see if I can figure out how to get this done

Thank you :hugs:

I am also curious how to pair this idea for mitigating fake/spoofed prompts along side the SuDo password login prompt, so to make the whole SuDo password prompt not as useless as some experts claim when leaving SuDo as a generic login prompt that has been faked/spoofed by Threat Actors (according to the experts not me)

Demonstrated from the examples cited within this topic thread post: