Default fedora-30 template asking for password that I don't have
fiftyfour...@gmail.com
Claudia
> Hello,
Oops, I forgot to reply to this. Sorry.
> I have a fresh installation of Qubes 4.0.2 on a Dell Inspiron 5593 with an untouched fedora-30
> template. Aside from some minor hiccups during installation, no compatibility issues have been
> detected. (Note: I know more about tech than the layperson, but not enough to call myself a
> 'techie').
>
> Following the instructions on the Qubes guide to randomizing my MAC address, I cloned the template
> and attempted to modify it for my netVMs. When creating the '00-macrandomizer.conf' file in the
> '/etc/NetworkManager/conf.d' folder, I was told that I don't have permission to do so. This struck
> me as odd, since I recently read Joanna's message in the sudoers' folder about passwordless root. I
> tried every password that I've set on the machine (including the root password set during
> installation), but nothing works.
>
> Anyone have any idea what's going on? In case it's relevant, the command line starts with "user".
If running as user, you'll get "Permission denied" but it won't ask for a password as far as I know. You need to put sudo in front of the command. This is when it would normally ask you for a password, but it *should* just work without asking for a password. Also, try using `su` with no arguments and see if that asks for a password also.
Also, don't type your dom0 passwords or disk password into VMs. You may want to change them just to be safe.
Run `sudo -l`, you should see
User user may run the following commands on fedora-30:
(ALL) NOPASSWD: ALL
(root) NOPASSWD: /bin/udevadm trigger --action\=add --sysname-match\=event[0-9]
When you're prompted for the password, check /var/log/xen/console/gues-fedora-30.log (on dom0) for any problems. You should see an audit line about the su or sudo command. Normally it should say "res=success" towards the end.
> P.S. Does creating a firewallVM just for TOR connection (i.e. proxy between whonix/TAILS appVM and
> whonix-15-gw netVM) increase security or just waste computational resources?
This came up a while back. I'll try to find the thread for you. In short, I remember reading in the Tor documentation that anyone with access to your SOCKSPort can potentially learn information about what sites you're visiting. So in that case, yes, separate whonix gateways would be beneficial. On the other hand, the Whonix developers know more about this than I do, and I'm assuming they did everything right. I never got around to investigating though. You might have better luck asking on the Whonix forum or Tor stack exchange.
Chris Laprise
> January 6, 2020 5:02 AM, fiftyfour...@gmail.com wrote:
>
>> Hello,
>
> Oops, I forgot to reply to this. Sorry.
>
>> I have a fresh installation of Qubes 4.0.2 on a Dell Inspiron 5593 with an untouched fedora-30
>> template. Aside from some minor hiccups during installation, no compatibility issues have been
>> detected. (Note: I know more about tech than the layperson, but not enough to call myself a
>> 'techie').
>>
>> Following the instructions on the Qubes guide to randomizing my MAC address, I cloned the template
>> and attempted to modify it for my netVMs. When creating the '00-macrandomizer.conf' file in the
>> '/etc/NetworkManager/conf.d' folder, I was told that I don't have permission to do so. This struck
>> me as odd, since I recently read Joanna's message in the sudoers' folder about passwordless root. I
>> tried every password that I've set on the machine (including the root password set during
>> installation), but nothing works.
>>
>> Anyone have any idea what's going on? In case it's relevant, the command line starts with "user".
>
> If running as user, you'll get "Permission denied" but it won't ask for a password as far as I know. You need to put sudo in front of the command. This is when it would normally ask you for a password, but it *should* just work without asking for a password. Also, try using `su` with no arguments and see if that asks for a password also.
>
> Also, don't type your dom0 passwords or disk password into VMs. You may want to change them just to be safe.
>
> Run `sudo -l`, you should see
> User user may run the following commands on fedora-30:
> (ALL) NOPASSWD: ALL
> (root) NOPASSWD: /bin/udevadm trigger --action\=add --sysname-match\=event[0-9]
>
> When you're prompted for the password, check /var/log/xen/console/gues-fedora-30.log (on dom0) for any problems. You should see an audit line about the su or sudo command. Normally it should say "res=success" towards the end.
sudo to be disabled by default. On these minimal templates, you can only
gain root privs by using 'qvm-run -u root' in dom0 or by using that
qvm-run command to install the 'qubes-core-agent-passwordless-root'
package which adds the no-password sudo capability back.
You can also tie sudo to a secure yes/no prompt:
https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt
https://github.com/tasket/Qubes-VM-hardening/blob/master/configure-sudo-prompt
>
>> P.S. Does creating a firewallVM just for TOR connection (i.e. proxy between whonix/TAILS appVM and
>> whonix-15-gw netVM) increase security or just waste computational resources?
>
> This came up a while back. I'll try to find the thread for you. In short, I remember reading in the Tor documentation that anyone with access to your SOCKSPort can potentially learn information about what sites you're visiting. So in that case, yes, separate whonix gateways would be beneficial. On the other hand, the Whonix developers know more about this than I do, and I'm assuming they did everything right. I never got around to investigating though. You might have better luck asking on the Whonix forum or Tor stack exchange.
extra firewall to VPN VMs, it just wastes resources. The VPN or Tor gw
already has 'low' attack surface and firewall capability, and they
typically filter which external gateways they do and don't talk to based
on crypto-enforced identification.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Claudia
> On 1/6/20 3:22 PM, Claudia wrote:
>
> I think s/he is really using a "minimal" template here. That would cause
> sudo to be disabled by default. On these minimal templates, you can only
> gain root privs by using 'qvm-run -u root' in dom0 or by using that
> qvm-run command to install the 'qubes-core-agent-passwordless-root'
> package which adds the no-password sudo capability back.
Oh, that's possible.
>>> P.S. Does creating a firewallVM just for TOR connection (i.e. proxy between whonix/TAILS appVM and
>>> whonix-15-gw netVM) increase security or just waste computational resources?
>>
>> This came up a while back. I'll try to find the thread for you. In short, I remember reading in the
>> Tor documentation that anyone with access to your SOCKSPort can potentially learn information about
>> what sites you're visiting. So in that case, yes, separate whonix gateways would be beneficial. On
>> the other hand, the Whonix developers know more about this than I do, and I'm assuming they did
>> everything right. I never got around to investigating though. You might have better luck asking on
>> the Whonix forum or Tor stack exchange.
>
> I think you'll find different opinions about this. IMO, as with adding
> extra firewall to VPN VMs, it just wastes resources. The VPN or Tor gw
> already has 'low' attack surface and firewall capability, and they
> typically filter which external gateways they do and don't talk to based
> on crypto-enforced identification.
Well, to me there's a difference between theoretical attack surfaces and stuff like that, versus official documentation telling you it's not safe to share SOCKSPorts. If that's the case, that is. It was a really long time ago and I don't remember what it said exactly. But yeah, I agree, I wouldn't necessarily go adding redundant VMs just out of paranoia. Personally I only run one whonix gateway even though I probably have enough ram to run a dozen.
fiftyfour...@gmail.com
fiftyfour...@gmail.com
Claudia
>> Also, try using `su` with no arguments and see if that asks for a password also.
>
> The problem was resolved by using the "su" command on its own (as opposed to "su user", which
> prompted me for a password), which brought me straight into "bash-5.0#", where I used the "cat >
> 00-macrandomizer.conf" command.
>
> Typing "sudo cat > test.txt" into the user (non-su) prompt returned "bash: test.txt: Permission
> denied".
Glad you got it working. In case you're curious: I think that means that `cat` was running as root, but bash, and therefore the '>' operator, was still running as user. The '>' takes precedence over the command. You can think of it like this: ((sudo cat) > test.txt).
>> Also, don't type your dom0 passwords or disk password into VMs. You may want to change them just
> to be safe.
>
> My machine has never been connected to the internet when I typed in the passwords (like, in the
> lifetime of the machine), so I figured they'll be safe unless a verified iso has been compromised,
> but I'll do things the Qubes way and change them anyways.
In theory, for example, fedora-30 could save the password somewhere in its root filesystem, which would be accessible later by a networked AppVM based on that template. It's very unlikely though. I was just covering all bases.
Chris Laprise
> January 7, 2020 5:07 AM, fiftyfour...@gmail.com wrote:
>
>>> Also, try using `su` with no arguments and see if that asks for a password also.
>>
>> The problem was resolved by using the "su" command on its own (as opposed to "su user", which
>> prompted me for a password), which brought me straight into "bash-5.0#", where I used the "cat >
>> 00-macrandomizer.conf" command.
>>
>> Typing "sudo cat > test.txt" into the user (non-su) prompt returned "bash: test.txt: Permission
>> denied".
>
> Glad you got it working. In case you're curious: I think that means that `cat` was running as root, but bash, and therefore the '>' operator, was still running as user. The '>' takes precedence over the command. You can think of it like this: ((sudo cat) > test.txt).
root first, but you'd have to do it indirectly like this:
$ sudo su -
You can also do it without a new shell:
$ cat | sudo tee test.txt