Re: [qubes-users] QSB #46: APT update mechanism vulnerability
On 2019-01-28 21:51, Alexandre Belgrand wrote: > Le lundi 28 janvier 2019 à 13:08 -0800, goldsm...@riseup.net a écrit : >> To Alexandre Belgrand >> >> I'm intrigued how you know can catagorically state "CAs and GNU/Linux >> distributions are #1 targets for national >> intelligence agencies". This is classified information and therefore >> only available to a "Spook". Otherwise, it's entered the public >> domain >> via say a whistle blower like Ed Snowden. If that's how you came upon >> it, please state the source and location. > > I am not a whistle blower, but I believe that all CAs and GNU/Linux > distributions are primary targets for Intelligence agencies. This is > not secret, this is why I am writing it, sitting behind my real IP. > > You will find this information on Internet. Look for the recent > problems with China for example. > > Stealing root certificates allow Intelligence agencies to set-up mirage > Internet : i.e. decrypt SSL/crypted content and present modified > content to the user and make man-in-the-middle attack. > > Think about Debian private keys. The keys are stored on a server in a > datacenter, not even on smartcards. What can stop a remote attacker > with a remote console (either directly or using Intel ME) from stealing > the keys and then breaking password using a keylogger in Intel ME. > Answer : nothing can stop a local government from doing so. > > Think about SSL X509 certificates. To deliver encrypted content, the > private key has to be on the server. You only need serial console > access to steal the private key. > > The only solution is to compile the same bytecode and verifying hashes > online, but Debian is lagging behind important patches, because they > don't understand what already happened. To Alexandre So you found this stuff on the internet and were gullible enough to swallow it, hook line and sinker, without first verifying its authenticity. I suppose your allegations against the Debian Team's security keys are based on equally unstable foundations. The making of serious random and unsolicited allegations with the intention of scaremongering, could be described as TROLLING. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0efc60370976fc6e0e12530b8a9c89e1%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On 2019-01-28 19:46, billol...@gmail.com wrote: > On Monday, January 28, 2019 at 10:27:32 AM UTC-5, gold...@riseup.net wrote: >> On 2019-01-27 19:15, billol...@gmail.com wrote: >> > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote: >> >>[snip] >> >> Qubes provides a framework for using software - it doesn't take away the >> >> onus on users to use that software properly, and to ensure they are aware >> >> of good practice. (As an aside I'm always baffled by people querying >> >> how they can use Facebook under Tor or Whonix. What are they thinking?) >> >> I regularly audit templates with tripwire, running from an >> >> offline openBSD qube, and do standards checks with debsums. I do good >> >> deal of my work offline in openBSD and then transfer encrypted in to >> >> other qubes for transmission. That seems like overkill, and isn't for >> >> everyone: it might be for you. >> >> >> >> unman >> > >> > I think this is the most important thing you wrote. I used to do >> > network security for a small scientific government network back in the >> > 1990s, and I constantly ran into the problem that there is an inverse >> > relationship between security and usability. The scientists on my >> > network were constantly finding ways of going around whatever security >> > measures I put in place precisely because they didn't want to deal >> > with the "hassle." >> > >> > But I'm no different, really. Not too many years ago, I routinely >> > disabled SELinux when I installed a new OS simply because I considered >> > it too much of a hassle to learn how to use it effectively. It made >> > it difficult for me to do stuff. Everybody yelled at me, but it just >> > wasn't worth the effort to me. Now, I've learned it a bit and it's not >> > such a hassle. >> > >> > There's this balance between the inconvenience/damage associated with >> > an intrusion versus the inconvenience associated with the security >> > configuration. For me on the computer I'm using as I write this, it >> > wouldn't be the end of the world if *everything* on my computer were >> > owned by someone else. It would be a hassle, but not fatal -- I have >> > insurance, etc. for the financial information I have here, and I don't >> > really care if someone sees the email conversations I have on this >> > machine. >> > >> > So, considering the financial stuff, for instance. There's a hassle >> > with someone getting my credit card information. It's happened >> > (though not because of a computer glitch). My card gets frozen, I >> > can't use it for a week or two, I have to make a bunch of phone calls, >> > etc. But I'm financially protected and eventually I'll be fine. The >> > problem is the hassle factor, not financial ruin. My biggest security >> > concern is someone using up all my bandwidth; I live in a rural area >> > and have metered service. Someone using up 5 gigs of bandwith is more >> > concerning to me than them owning 5 gigs of data from my machine. So, >> > I have to ask myself, which is more hassle -- dealing with the >> > intrusion, or dealing with the security hassle? >> > >> > It's my responsibility to determine where that balance is, and nobody >> > else's. And it's likely different for everybody. For instance, I >> > used to have a blog, but I'm a litigation consultant and I started >> > seeing my blog posts turning up in court. So I don't blog any more. I >> > can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate. >> > That's not a problem for me, but it would drive my wife crazy. I use >> > one laptop for some stuff, and I use a different laptop, differently >> > configured, for other stuff. >> > >> > And, the higher up the food chain you go with respect to people >> > interested in surveilling you, the less chance you have of keeping >> > them out. I'm out of the business now, but back in the day I >> > occasionally did some classified work. I remember some years ago, I >> > called a friend of mine who worked for the government. I called him >> > using the work phone of an acquaintance to ask him a technical >> > question. He picked up the phone and immediately said "Hey, Bill, how >> > you doing?" >> > >> > I was stunned. I asked him how the hell he knew it was me. He said >> > "Bill, I'm with the . We always know where you >> > are." >> > >> > I have another friend who spent his early career working for a >> > government contractor. His job was to break into people's houses at >> > night and install keyloggers on their computers. With a subpoena, of >> > course. All the security software in the world won't help you with >> > that. >> > >> > The key, for me, is to achieve the maximum security that I can achieve >> > and stay below my maximum hassle tolerance. Qubes is nice because it >> > adds a big uptick in transparent security with only a small uptick in >> > hassle -- at least for someone who is fairly conversant with sysadmin >> > stuff. So for me it's a big win. But it's not all th
Re: [qubes-users] QSB #46: APT update mechanism vulnerability
On 2019-01-27 14:33, Alexandre Belgrand wrote: > Le dimanche 27 janvier 2019 à 13:11 +, Holger Levsen a écrit : >> I *believe* they probably misunderstood evil32.com and it's fallout. > > CAs and GNU/Linux distributions are #1 targets for national > intelligence agencies. > > Debian developers are not using smartcards to store their GPG keys, > including the master key signing code. It is very likely that Debian > master key has been stolen. I would be very surprised if it had not > been stolen. > > One reason why nobody wants to use SSL, including OpenBSD, is that > there is a wide belief that SSL private keys have been stolen. > Therefore there is no need to use SSL, as it does not offer a real > protection. > > This is simply GAME OVER (part 1 of the game). > > One reason why I am not using Qubes, is that it does not offer a real > protection compared to Debian, as both systems are IMHO compromised. > > At present, any government with a valid certificate from Intel can use > Intel ME backdoor to access all resources from a computer, including > keyboard and screen and there is no way to secure an X86 computer. > > If Qubes was making a wide use of Smartcards with a separate pinpad > reader and was using a hardened operating system like OpenBSD or even a > hardened GNU/Linux, I would have a closer look at it. To Alexandre Belgrand I'm intrigued how you know can catagorically state "CAs and GNU/Linux distributions are #1 targets for national intelligence agencies". This is classified information and therefore only available to a "Spook". Otherwise, it's entered the public domain via say a whistle blower like Ed Snowden. If that's how you came upon it, please state the source and location. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2b8a5894a649357c09b0664a2f023245%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On 2019-01-27 19:15, billol...@gmail.com wrote: > On Sunday, January 27, 2019 at 12:22:03 PM UTC-5, unman wrote: >>[snip] >> Qubes provides a framework for using software - it doesn't take away the >> onus on users to use that software properly, and to ensure they are aware >> of good practice. (As an aside I'm always baffled by people querying >> how they can use Facebook under Tor or Whonix. What are they thinking?) >> I regularly audit templates with tripwire, running from an >> offline openBSD qube, and do standards checks with debsums. I do good >> deal of my work offline in openBSD and then transfer encrypted in to >> other qubes for transmission. That seems like overkill, and isn't for >> everyone: it might be for you. >> >> unman > > I think this is the most important thing you wrote. I used to do > network security for a small scientific government network back in the > 1990s, and I constantly ran into the problem that there is an inverse > relationship between security and usability. The scientists on my > network were constantly finding ways of going around whatever security > measures I put in place precisely because they didn't want to deal > with the "hassle." > > But I'm no different, really. Not too many years ago, I routinely > disabled SELinux when I installed a new OS simply because I considered > it too much of a hassle to learn how to use it effectively. It made > it difficult for me to do stuff. Everybody yelled at me, but it just > wasn't worth the effort to me. Now, I've learned it a bit and it's not > such a hassle. > > There's this balance between the inconvenience/damage associated with > an intrusion versus the inconvenience associated with the security > configuration. For me on the computer I'm using as I write this, it > wouldn't be the end of the world if *everything* on my computer were > owned by someone else. It would be a hassle, but not fatal -- I have > insurance, etc. for the financial information I have here, and I don't > really care if someone sees the email conversations I have on this > machine. > > So, considering the financial stuff, for instance. There's a hassle > with someone getting my credit card information. It's happened > (though not because of a computer glitch). My card gets frozen, I > can't use it for a week or two, I have to make a bunch of phone calls, > etc. But I'm financially protected and eventually I'll be fine. The > problem is the hassle factor, not financial ruin. My biggest security > concern is someone using up all my bandwidth; I live in a rural area > and have metered service. Someone using up 5 gigs of bandwith is more > concerning to me than them owning 5 gigs of data from my machine. So, > I have to ask myself, which is more hassle -- dealing with the > intrusion, or dealing with the security hassle? > > It's my responsibility to determine where that balance is, and nobody > else's. And it's likely different for everybody. For instance, I > used to have a blog, but I'm a litigation consultant and I started > seeing my blog posts turning up in court. So I don't blog any more. I > can't be on Facebook, or LinkedIn, or Doximity, or ResearchGate. > That's not a problem for me, but it would drive my wife crazy. I use > one laptop for some stuff, and I use a different laptop, differently > configured, for other stuff. > > And, the higher up the food chain you go with respect to people > interested in surveilling you, the less chance you have of keeping > them out. I'm out of the business now, but back in the day I > occasionally did some classified work. I remember some years ago, I > called a friend of mine who worked for the government. I called him > using the work phone of an acquaintance to ask him a technical > question. He picked up the phone and immediately said "Hey, Bill, how > you doing?" > > I was stunned. I asked him how the hell he knew it was me. He said > "Bill, I'm with the . We always know where you > are." > > I have another friend who spent his early career working for a > government contractor. His job was to break into people's houses at > night and install keyloggers on their computers. With a subpoena, of > course. All the security software in the world won't help you with > that. > > The key, for me, is to achieve the maximum security that I can achieve > and stay below my maximum hassle tolerance. Qubes is nice because it > adds a big uptick in transparent security with only a small uptick in > hassle -- at least for someone who is fairly conversant with sysadmin > stuff. So for me it's a big win. But it's not all there is. > > There's no such thing as perfect security. There's only finding the > balance between one's perceived risk, one's actual vulnerability, and > one's tolerance for hassle. And any security configuration is > self-defeating if: > > 1) People take it for granted and think that it's all they have to > think about, and/or > 2) It's enough of a hassle that
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On 2019-01-27 01:34, unman wrote: > On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote: >> >> Am I right in thinking that the recently discovered apt vulnerability >> (DSA 4371-1) in Debian based systems could and should have been >> mitigated against many years ago by downloading and activating an apt >> package; "apt-transport-https", which forces apt updates via https? The >> researcher (Max Justicz) who discovered the vulnerability has stated it >> couldn't have been exploited if https had been implemented. >> >> If "apt-transport-https" is the magic bullet, why in the past hasn't it >> been implemented by default? And, why for the future, is it not being >> implemented immediately by Qubes, Debian et al? >> >> During the past decade many people with good foresight had predicted the >> apt vulnerabilty and urged administrators to install the >> solution;"apt-transport-https". Regrettably, the vocal majority of >> so-called experts said that's unnecessary because the packages are >> signed. Was that incompetent advice? or was it a coordinated response >> from agents of State Actors to hide a deliberate backdoor? I've no idea, >> but given Snowdens revelations I would not rule anything out. > > No you're not right in thinking this. > You seem to have missed the section where Max explicitly say that "a > malicious mirror could still exploit a bug like this, even with https." > So apt-transport-https is no magic bullet, particularly as a cursory > glance suggests that it allows forcing SSL version to SSLv3, which is > known to be insecure. > > Imagine that apt-transport-https *had* been adopted - have you actually > looked at the list of vulnerabilities in libcurl, and the various > breakages in the TLS CA system? I can imagine some one > posting exactly like you: "Was the move to https incompetent advice? or > was it a coordinated response from agents of State Actors to hide a > deliberate backdoor? I've no idea, but given Snowdens revelations I > would not rule anything out." > > I would rule some things out. And in this case it looks like a simple > mistake. And if you read any of the arguments re http/https you'd see > that there are reasonable arguments on both sides, and the "so called > experts" took reasoned positions. > > It's always been open to you to install the package and switch to https > transport in your Debian templates, of course. And Qubes had already > started to use that by default too. > Not to downplay the importance of the bug, but let's not lose > our heads. Apologies. I've reposted this because the subscripts weren't clear in the earlier post. Hopefully this will be clearer. Thank you for your responses. I appear to have prodded a hornets nest! I make no apology for that. It’s good and allows everyone an opportunity to express their views. Hopefully backed up by facts. Here's some background as to where I'm coming from: 1/ I use Debian based templates; including Whonix, exclusively (I do have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat, monetised etc). So, all my apps (including service apps like sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited. At this point for me its game over. I'm completely stuffed. Now when Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the vulnerability was publicly announced, saying its comparable to a firefox exploit: I get angry and say what complete and utter PR horsesh*t. 2/ Nobody's going to blame Qubes for an vulnerability like this in Debian etc. However, the least I'd expect from Qubes is a timely warning. Personally, I got a warning from Whonix a good 12 hrs before Qubes alerted us! 3/ Most people have made an assumption that the good guys i.e. Max Justicz found the vulnerability first. Personally I never assume anything and prefer to think "worst case scenario". In this case I have had no privacy or security whatsoever for possibly years. Whilst Dom0's been protected, I'm not - what use is that? Now turning to Unman's comments: 1/ no you're not right in thinking this. you seem to have missed the section where max explicitly say that "a malicious mirror could still exploit a bug like this, even with https." so apt-transport-https is no magic bullet, particularly as a cursory glance suggests that it allows forcing ssl version to sslv3, which is known to be insecure. With respect Unman, you seem to have missed the section where Max explicitly says "Supporting http is fine. I just think it’s worth making https repositories the default the safer default and allowing users to downgrade their security at a later time if they choose to do so". Furthermore, The Guardian Project have been promoting the use of https for apt package retrieval for many years. Here's their latest statement; "There is a new vulnerability in Debian’s apt that allows anything that can Man-in-the-Middle (MITM) your traffic to get root on your Debian/Ubuntu/etc boxes. Using encrypted
Re: [qubes-users] Debian Template APT Vulnerability - A ticking bomb?
On 2019-01-27 01:34, unman wrote: > On Sat, Jan 26, 2019 at 04:39:45AM -0800, goldsm...@riseup.net wrote: >> >> Am I right in thinking that the recently discovered apt vulnerability >> (DSA 4371-1) in Debian based systems could and should have been >> mitigated against many years ago by downloading and activating an apt >> package; "apt-transport-https", which forces apt updates via https? The >> researcher (Max Justicz) who discovered the vulnerability has stated it >> couldn't have been exploited if https had been implemented. >> >> If "apt-transport-https" is the magic bullet, why in the past hasn't it >> been implemented by default? And, why for the future, is it not being >> implemented immediately by Qubes, Debian et al? >> >> During the past decade many people with good foresight had predicted the >> apt vulnerabilty and urged administrators to install the >> solution;"apt-transport-https". Regrettably, the vocal majority of >> so-called experts said that's unnecessary because the packages are >> signed. Was that incompetent advice? or was it a coordinated response >> from agents of State Actors to hide a deliberate backdoor? I've no idea, >> but given Snowdens revelations I would not rule anything out. > > No you're not right in thinking this. > You seem to have missed the section where Max explicitly say that "a > malicious mirror could still exploit a bug like this, even with https." > So apt-transport-https is no magic bullet, particularly as a cursory > glance suggests that it allows forcing SSL version to SSLv3, which is > known to be insecure. > > Imagine that apt-transport-https *had* been adopted - have you actually > looked at the list of vulnerabilities in libcurl, and the various > breakages in the TLS CA system? I can imagine some one > posting exactly like you: "Was the move to https incompetent advice? or > was it a coordinated response from agents of State Actors to hide a > deliberate backdoor? I've no idea, but given Snowdens revelations I > would not rule anything out." > > I would rule some things out. And in this case it looks like a simple > mistake. And if you read any of the arguments re http/https you'd see > that there are reasonable arguments on both sides, and the "so called > experts" took reasoned positions. > > It's always been open to you to install the package and switch to https > transport in your Debian templates, of course. And Qubes had already > started to use that by default too. > Not to downplay the importance of the bug, but let's not lose > our heads. Thank you for your responses. I appear to have prodded a hornets nest! I make no apology for that. It’s good and allows everyone an opportunity to express their views. Hopefully backed up by facts. Here's some background as to where I'm coming from: 1/ I use Debian based templates; including Whonix, exclusively (I do have doubts about Fedora’s integrity; calls home, owned by IBM/Redhat, monetised etc). So, all my apps (including service apps like sys-firewall, sys-net sys-usb) are compromised if Debian gets exploited. At this point for me its game over. I'm completely stuffed. Now when Qubes eventually issues a QSB; Security Bulletin almost 24 hrs after the vulnerability was publicly announced, saying its comparable to a firefox exploit: I get angry and say what complete and utter PR horsesh*t. 2/ Nobody's going to blame Qubes for an vulnerability like this in Debian etc. However, the least I'd expect from Qubes is a timely warning. Personally, I got a warning from Whonix a good 12 hrs before Qubes alerted us! 3/ Most people have made an assumption that the good guys i.e. Max Justicz found the vulnerability first. Personally I never assume anything and prefer to think "worst case scenario". In this case I have had no privacy or security whatsoever for possibly years. Whilst Dom0's been protected, I'm not - what use is that? Now turning to Unman's comments: 1/ no you're not right in thinking this. you seem to have missed the section where max explicitly say that "a malicious mirror could still exploit a bug like this, even with https." so apt-transport-https is no magic bullet, particularly as a cursory glance suggests that it allows forcing ssl version to sslv3, which is known to be insecure. With respect Unman, you seem to have missed the section where Max explicitly says "Supporting http is fine. I just think it’s worth making https repositories the default the safer default and allowing users to downgrade their security at a later time if they choose to do so". Furthermore, The Guardian Project have been promoting the use of https for apt package retrieval for many years. Here's their latest statement; "There is a new vulnerability in Debian’s apt that allows anything that can Man-in-the-Middle (MITM) your traffic to get root on your Debian/Ubuntu/etc boxes. Using encrypted connections for downloading updates, like HTTPS or Tor Onion Services, reduces this vulnerability to requiring root on th
[qubes-users] Debian Template APT Vulnerability - A ticking bomb?
Am I right in thinking that the recently discovered apt vulnerability (DSA 4371-1) in Debian based systems could and should have been mitigated against many years ago by downloading and activating an apt package; "apt-transport-https", which forces apt updates via https? The researcher (Max Justicz) who discovered the vulnerability has stated it couldn't have been exploited if https had been implemented. If "apt-transport-https" is the magic bullet, why in the past hasn't it been implemented by default? And, why for the future, is it not being implemented immediately by Qubes, Debian et al? During the past decade many people with good foresight had predicted the apt vulnerabilty and urged administrators to install the solution;"apt-transport-https". Regrettably, the vocal majority of so-called experts said that's unnecessary because the packages are signed. Was that incompetent advice? or was it a coordinated response from agents of State Actors to hide a deliberate backdoor? I've no idea, but given Snowdens revelations I would not rule anything out. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9e814631ba39955e16a2ff28096b58e7%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-devel] QSB #46: APT update mechanism vulnerability
On 2019-01-23 21:08, gone wrote: > unfortunately the reboot brought no change. Still the > 201812091508 version. Try sudo qubes-dom0-update --enablerepo=qubes-templates-itl-testing qubes-template-debian-9 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/13bb066f990aff75a307a5589d1fdd5b%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qvm-prefs clockvm command fails
On 2019-01-20 23:57, unman wrote: > On Sun, Jan 20, 2019 at 04:42:12AM -0800, goldsm...@riseup.net wrote: >> I'm following qubes docs >> https://www.qubes-os.org/doc/disposablevm-customization/ and trying to >> set clockvm to disp-sys-net using command in Dom0 qvm-prefs clockvm >> disp-sys-net >> which gives message: qvm-prefs: error: no such domain clockvm. Have >> tried variations of clockvm e.g. ClockVM to no avail. >> >> As an alternative fix, I set clockvm to disp-sys-net in gui "global >> settings". Buy not sure its working > > Look again - that should be qubes-prefs not qvm-prefs Thanks Unman That was a dumb mistake on my part. Sorry to waste your time -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c02ab937f1ee35e7b4a2d4a2326863a2%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0.x - Linux kernel 4.19.15 package available in testing repository
On 2019-01-20 00:57, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi all, > > There is updated "kernel" package available in current-testing > repository - it's a Linux long term support 4.19.x series, as an update > over 4.14.x before. Since the upgrade switches to the next major LTS > branch, I'll keep it in current-testing repository longer than usual 1-2 > weeks. This also applies to kernel package for VMs: kernel-qubes-vm. > Please report new issues the usual way, at qubes-issues[1], or > simply by replying here. In either case, please mark it clearly it > happens after updating to 4.19, preferably including a link to the > update: > https://github.com/QubesOS/updates-status/issues/850 > > 4.19.x kernel was already available as kernel-latest package for some > time. Users of kernel-latest will see the update to 4.19.15 too, but > kernel-latest soon will carry 4.20.x kernel version. > > [1] https://github.com/QubesOS/qubes-issues/issues > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlxDx4YACgkQ24/THMrX > 1ywtlgf9HE/mQmGQIZtymeLHdeAP6FnpBhGrbaJESWM2AhFxRFIQpGLEBIIrpKvH > K6aFYqbFPNHYPE2DnboHmHebP1But8krrSbi4Ig5Z6E1pTFIk9XTrPQSbyY8jei9 > hGY6Y8NRdTB3ljAbQpdLmfvmq9LksBQox9V5v+7lbNd6IhFOuqYnfcjz/P6PWO/F > Np/orRT2QEB5Hzuqgm8dnfKUY1NBiwE1Nbxe2vl9OqrEkpceo4sKpBhEpF3LX7Z4 > aTjroOnfk4Hrb2souyTKuVhRaBdHP3wxxof+xNcsakFQNp96Jeh/2b/+im6CSaEa > 9BUaPC82RwFT//o8TvYwyybX8wuLpg== > =nKaU > -END PGP SIGNATURE- Feedback The only minor bug I've noticed is: the encrypted disk password gui screen is missing at login. However, login remain available via terminal -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e34715ac1a25c72b44182215d6ae57b3%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-prefs clockvm command fails
I'm following qubes docs https://www.qubes-os.org/doc/disposablevm-customization/ and trying to set clockvm to disp-sys-net using command in Dom0 qvm-prefs clockvm disp-sys-net which gives message: qvm-prefs: error: no such domain clockvm. Have tried variations of clockvm e.g. ClockVM to no avail. As an alternative fix, I set clockvm to disp-sys-net in gui "global settings". Buy not sure its working -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/640b59d2d3bd187a8f6e8bb5f51bc8e4%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: Fwd: Re: [qubes-users] Mirage-Firewall - Trusted in Dom0?
On 2019-01-19 13:46, Illidan Pornrage wrote: > On 1/18/19 5:02 PM, Goldi wrote: >> >> >> >> Original Message >> From: goldsm...@riseup.net >> Sent: January 18, 2019 3:45:06 PM UTC >> To: unman >> Subject: Re: [qubes-users] Mirage-Firewall - Trusted in Dom0? >> >> On 2019-01-18 13:52, unman wrote: >>> On Fri, Jan 18, 2019 at 04:38:56AM -0800, goldsm...@riseup.net wrote: On 2019-01-15 15:19, Goldi wrote: > I've been happily using Qubes for several years and noticed that > several prominent members of the Qubes Team have in the past suggested > installing Mirage-Firewall as an alternative to Sys-Firewall. However, > I cannot find any reference to MF in the Qubes Docs. > I'd like to install Mirage-Firewall, but I have a nagging doubt about > whether the code can be trusted. Particularly as it has to been > installed in Dom0 > What do you guys recommend? Can the MF developer be trusted? > > https://groups.google.com/d/msgid/qubes-users/21F0DB51-AF5A-4729-8708-14C54BB4C29A%40riseup.net?utm_medium=email&utm_source=footer In Nov 2018 a prominent member of the Qubes team; Unman suggested using Mirage-Firewall. I'd appreciate very much a reply to my earlier query about the integrity and reliability of the code/developer of Mirage Firewall >>> >>> There is a reference in the docs to GSOC potential work: otherwise >>> you'll find discussions here and in qubes-devel, and there's an open >>> issue in qubes-issues. >>> I have no view on the integrity of Thomas - don't know him. His >>> contributions have been good and he's always seemed helpful and to know >>> what he's talking about. >>> You can look at the code yourself and come to view on that: it's >>> pretty straightforward. >>> https://github.com/talex5/qubes-mirage-firewall >>> >>> I've done some testing, and the firewall works as expected, with no >>> strange effects I could see. >> Thank you for responding. >> I think I'll pass on installing Mirage-Firewall. I'm a user and >> regretfully not competent to review MF code. I had hoped that any >> recommendation to install anything in Dom0 would have been first >> thoroughly assessed by the qubes team. After all, if Dom0 is compromised >> its as Joanna used to say "game over" >> > > Ok, a short update for you. I am interested in it too and currently > reviewing it. > > The qubes mirage firewall is a kernel binary that is just stored in > dom0 (+ initramfs and modules storage image), not executed in dom0. > (The initramfs is usually the first program started by a linux kernel. > The modules.img is an image that is available as volume in the qube to > pull extra modules for a linux kernel from. As this is a mirage > unikernel and not a linux kernel the modules.img is empty. The > initramfs contains a part of the firewall.) > It can then be chosen in qubes settings > advanced > kernel, per qube. > This is just a kernel only without extra os that is run in the firewall qube. > > Risks: > - If whatever puts the kernel into a qube to boot from it can be > exploited using a malformed kernel file <-- imo low risk but no > guarantee as I havent reviewed that part of the hypervisor code. > - The installer is corrupted and puts evil things in the rpm for dom0 > <-- from the github it isnt even an rpm, just a tarball that gets spit > out by the builder or downloaded as release from github. So great > transparence. > - The firewall being leaky because of bugs or maliciously or the build > script being manipulated maliciously. <-- It is built in a docker > container. The github repo contains the dockerfile which actually > verifies its base image using sha256, the maintainer seems to care > about reproducibility. Mirage libraries get fetched via the opam OCAML > file manager. Which might check signatures on those. Up to > verification. > > All in all pretty safe to use. Wow. That's a good comprehensive reply. Thank you. It goes a long way to convincing me that the code is safe to use. Does any one else have any feedback on this issue? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7427343df1d9b1e9dd055eae384d40b3%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes Updates - Broken?
Qubes 4 -testing version Qubes updates widget informs there are 4 updates available --> launch updater highlights only 2 updates available (debian 9 template & whonix-gw-14) I select update all. Perversely, debian9 and whonix-gw are not updated, but my 2 fedora templates are updated. After all this the updates widget is still showing 4 updates available. --> rebooted but same status. Tried updating via terminal but "no updates available". -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c60f15a053b58960507ed9347efd7dbf%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Mirage-Firewall - Trusted in Dom0?
On 2019-01-15 15:19, Goldi wrote: > I've been happily using Qubes for several years and noticed that > several prominent members of the Qubes Team have in the past suggested > installing Mirage-Firewall as an alternative to Sys-Firewall. However, > I cannot find any reference to MF in the Qubes Docs. > I'd like to install Mirage-Firewall, but I have a nagging doubt about > whether the code can be trusted. Particularly as it has to been > installed in Dom0 > What do you guys recommend? Can the MF developer be trusted? > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > -- > You received this message because you are subscribed to the Google > Groups "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to qubes-users+unsubscr...@googlegroups.com. > To post to this group, send email to qubes-users@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/21F0DB51-AF5A-4729-8708-14C54BB4C29A%40riseup.net > [1]. > For more options, visit https://groups.google.com/d/optout. > > > Links: > -- > [1] > https://groups.google.com/d/msgid/qubes-users/21F0DB51-AF5A-4729-8708-14C54BB4C29A%40riseup.net?utm_medium=email&utm_source=footer In Nov 2018 a prominent member of the Qubes team; Unman suggested using Mirage-Firewall. I'd appreciate very much a reply to my earlier query about the integrity and reliability of the code/developer of Mirage Firewall -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a229074dcf38cbaf69477a209e0e58b1%40riseup.net. For more options, visit https://groups.google.com/d/optout.
