> My guess is that Paypal is giving you a hard time just because of the
> tor exits you use to interact with their website.
Could be. At first I didn't see how/why, but I guess refusing a legit
password from what they judge as a dodgy IP address is a possibility.
(Although accepting the password
>> When I returned home, I tried logging in again, but from a different VM.
>> Failed repeatedly. I figured I must have messed up the password. No
>> luck
>> trying other possibilities.
I'm still a bit suspicious that one of my VM's has been compromised. I
still saw password problems after rest
I would say so, yes.
I think exim, cups, and possibly some gvfs-samba thing were also all
enabled on both the Fedora and debian-8 templates.
I personally don't like having those on by default in all the VMs,
listening on ports and poking around the network or Internet, as they
really should only
> When I returned home, I tried logging in again, but from a different VM.
> Failed repeatedly. I figured I must have messed up the password. No luck
> trying other possibilities.
Update: a signed message from SIGAINT indicating it was a system problem:
-BEGIN PGP SIGNED MESSAGE-
Hash:
>> On 08/23/2016 06:01 PM, johnyju...@sigaint.org wrote:
>>> Wow, what a weird day.
>>>
>>> A rather bizarre story, which is possibly a good example as to how
>>> Qubes
>>> can help protect you from hacking, or at least spot the effects of it.
>>
>> What threat model does this fit? If a skilled att
> On 08/23/2016 06:01 PM, johnyju...@sigaint.org wrote:
>> Wow, what a weird day.
>>
>> A rather bizarre story, which is possibly a good example as to how Qubes
>> can help protect you from hacking, or at least spot the effects of it.
>
> What threat model does this fit? If a skilled attacker trick
Wow, what a weird day.
A rather bizarre story, which is possibly a good example as to how Qubes
can help protect you from hacking, or at least spot the effects of it.
I use a sigaint address, because of a psycho ex and her corrupt cop buddies.
Anyhow, I created another sigaint address today, to
> How does Qubes perform as the host OS in a virtualised server environment?
>
> I'm thinking of a configuration where the host OS is Qubes with VM's
> running for things like a virtualised email server, IDS server, perhaps a
> Tor relay etc. I've used Qubes as a desktop host, I'm just curious abou
I know I may be in the minority with an under-powered machine (4G), but I
thought I'd share some tips for getting more room for additional AppVM's
that worked well for me:
I guess I should state that this really would "void your warrantee" and
you shouldn't hassle the Qubes folks with problems you
> On 08/22/2016 10:47 AM, johnyju...@sigaint.org wrote:
>> I'm trying to create a ProxyVM of my own, to replace sys-firewall.
>>
>> I'm on 3.2rc2-testing.
>>
>> When I create a ProxyVM in either fedora23 or debian-8, eth0 shows up,
>> but
>> no vif interface appears.
>>
>
> vif interfaces appear wh
> On 2016-08-22 07:52, johnyju...@sigaint.org wrote:
>> /rw/config/rc.local doesn't seem to be run on startup in debian-8
>> (3.2-testing).
>>
>> What is supposed to launch this? systemd, another startup script, or
>> something dom0-related?
>>
>> I added "/rw/config/rc.local" to "/etc/rc.local" a
I notice in the debian-8 template that network time synchronization seems
to be on by default in systemd.
systemd-timesyncd.service loaded active running Network Time
Synchronization
time-sync.target loaded active activeSystem Time Synchronized
It's disabled in fedora-23 by defau
> In trying to figure out why my ProxyVM has no VIF (on Qubes 3.2-testing) I
> was looking at the dmesg's of the servicevm's, and noticed something that
> looked a bit odd (running rapidly through vif interface #'s) in sys-net
> (fedora23 template).
> Similarly, iptables-save shows duplicate rules
> Added testing repos to (clones of) debian-23 and debian-8 templates (as
> well as whonix-gw/whonix-ws), did upgrades/dist-updates, restarted, loaded
> up a bunch of AppVM's, and have been pounding on things awhile.
>
> No sign of screen garbage yet! :)
>
> Looks promising.
Day 3 of banging on r
In trying to figure out why my ProxyVM has no VIF (on Qubes 3.2-testing) I
was looking at the dmesg's of the servicevm's, and noticed something that
looked a bit odd (running rapidly through vif interface #'s) in sys-net
(fedora23 template).
Is this normal?:
[ 42.978214] IPv6: ADDRCONF(NETDEV_U
I'm trying to create a ProxyVM of my own, to replace sys-firewall.
I'm on 3.2rc2-testing.
When I create a ProxyVM in either fedora23 or debian-8, eth0 shows up, but
no vif interface appears.
There are iptables entries for 10.137.4.*, so the firewall mechanism seems
to be doing (part of) it's thi
/rw/config/rc.local doesn't seem to be run on startup in debian-8
(3.2-testing).
What is supposed to launch this? systemd, another startup script, or
something dom0-related?
I added "/rw/config/rc.local" to "/etc/rc.local" and it works, but was
wondering what might be the official way to do this
> On Friday, August 5, 2016 at 1:52:12 AM UTC+8, Torsten Grote wrote:
>> I tried it now and it works, but is barely usable, because it is
>> very(!!!) slow. On top of running ARM emulation in an AppVM, I needed to
>> turn on software graphic rendering, because hardware rendering didn't
>> work.
>
>
> I see the updated packages are for qubes-gui-agent's in the fedora/debian
> templates. Will grab those, fire up several AppVM's, and see if things
> improve.
Added testing repos to (clones of) debian-23 and debian-8 templates (as
well as whonix-gw/whonix-ws), did upgrades/dist-updates, restarte
>> Several packages were recently pushed to testing repos (see
>> qubes-buider-github comments on the issue). Have you had a chance to try
>> those?
>
> Cool, I will grab the latest qubes-gui-vm from current-testing and see if
> that helps.
Sorry, that was phrased wrong, and I hate to add any conf
> On 2016-08-19 05:11, johnyju...@sigaint.org wrote:
>> When I try to run qvm-run from within an AppVM, I get "Request refused."
>>
>> Is this by design, for security reasons? If so, I guess that's
>> perfectly
>> reasonable. I just don't see that fact documented anywhere.
>>
>
> Yes, but it's co
>> This problem persists in 3.2rc2.
>>
>> (And I get 0 errors on the same USB drive under Tails. When I can find
>> the SATA power connector around here somewhere, I'll try moving the
>> drive
>> direct onto the SATA bus.)
>
> I think the problem *may* be that systemd has a default 90 second timeo
Is there any qvm-* command, or other method, to programmatically copy to
the qubes clipboard?
(Similar to my last question, a perfectly reasonable answer might be "of
course not, are you crazy?" due to security concerns. Requiring explicit
dom0/GUI user interaction for clipboard manipulation seem
When I try to run qvm-run from within an AppVM, I get "Request refused."
Is this by design, for security reasons? If so, I guess that's perfectly
reasonable. I just don't see that fact documented anywhere.
(The demonstration of one of the Xen exploits executes a qvm-run of xcalc
in dom0 from an
> This problem persists in 3.2rc2.
>
> (And I get 0 errors on the same USB drive under Tails. When I can find
> the SATA power connector around here somewhere, I'll try moving the drive
> direct onto the SATA bus.)
I think the problem *may* be that systemd has a default 90 second timeout
on jobs,
However, under Qubes, I experience random screen corruption.
See: https://i.imgur.com/ovEFgYO.png
> This problem persists in 3.2rc2.
>
> JJ
Actually, just FYI, the behavior seems to be a lot better under 3.2rc2.
I've only seen it a couple of times, versus seeing it consistently un
This problem persists in 3.2rc2.
JJ
>>> However, under Qubes, I experience random screen corruption.
>>>
>>> See: https://i.imgur.com/ovEFgYO.png
>
>> Looks like it could be this issue:
>>
>> https://github.com/QubesOS/qubes-issues/issues/1028
>>
>> As you can see from the qubes-builder-github co
The Qubes security team has written:
> Consequently, we have decided to move to hardware memory
> virtualization for the upcoming Qubes 4.0 release [4].
And Joanna has written:
> For Qubes 4 we want to move away from using PV as the default
> method of virtualization in favor of using hw-aided (
This problem persists in 3.2rc2.
(And I get 0 errors on the same USB drive under Tails. When I can find
the SATA power connector around here somewhere, I'll try moving the drive
direct onto the SATA bus.)
> Thanks for the feedback. The fact USB is a bad idea all around for
> security (and poten
On the Signal matter, just some personal paranoia Re: Signal and Google
Play Services:
I've been the subject of some rather intense and ongoing hacking (iPhone,
iPad, Android phone/tablet, PC, MacBook, cable modem connection, you name
it).
On the Android phone, I wiped it several times, and switc
Thanks for the feedback. The fact USB is a bad idea all around for
security (and potentially stability), and the fact I was getting minor
corruption, should have been a warning to me to move the drive right onto
the SATA bus, rather than risking worse corruption. I guess I only have
myself to bla
Well, my wild enthusiasm with Qubes has turned into complete frustration
and exasperation this morning.
The "mild" corruption I was seeing on boot (running Qubes from a USB 2.5"
HD) wasn't quite so mild the last time I booted.
This time, rather than "recovering journal... done," the fsck spewed m
One of the banes of a Qubes addict's existence is memory.
Too many times I see that red stop sign and breathe a sigh of frustration,
that I need to shut down or mem-set other VM's to start up another AppVM.
I like my VM separation, dammit, which means lots of VMs.
In a perfect world, I'd have a
>> However, under Qubes, I experience random screen corruption.
>>
>> See: https://i.imgur.com/ovEFgYO.png
> Looks like it could be this issue:
>
> https://github.com/QubesOS/qubes-issues/issues/1028
>
> As you can see from the qubes-builder-github comments, some patches for
> this
> are already i
I realize that nVidia's aren't the preferred video card, but (being
divorce-poor) one sometimes has to make do with what one has. :)
With my on-board nVidia (GeForce7100) and the nouveau driver (on both
Tails and Qubes), things work okay, then suddenly at some random point the
screen gets filled
>> Say you have a VM (e.g. "Banking only"), which has a NetVM of
>> sys-firewall,
>> but for which you have disallowed or greatly restricted networking,
>> turned
>> off DNS and ICMP, but left on "allow connection to updates proxy."
>>
>
> That box should be unchecked by default in AppVMs and check
I realize USB drives (or USB *anything*) is a stupid, stupid idea when it
comes to being security conscious, but while trying out Qubes, I do have
my root drive on an external USB HD.
(And there's something to be said for taking your drive with you.)
It works great in general, is fast enough, and
Greetings, Qubers.
Say you have a VM (e.g. "Banking only"), which has a NetVM of
sys-firewall, but for which you have disallowed or greatly restricted
networking, turned off DNS and ICMP, but left on "allow connection to
updates proxy."
As I understand it, this creates rules in sys-firewall to en
101 - 138 of 138 matches
Mail list logo
