Not sure if you’re asking but if you create a named disposable (using a disposable VM template), the IP address of the VM is stable. My VPN proxyVM is fully volatile and contains a firewall script that references the static IP.
Opensnitch would be good…Would that one be installed in sys-firewall?
it need to installed on every qubes (every template, hvm and standalone for more accurate)
1 Like
Ok, thanks.
And that is the reason they not really exists in practice.
Because you must believe that a ‘blessed code’ will going to detect the ‘evil’s code’, while booth running on the same permission levels 
not totally imo, it exist, but not very effective
and if the firewall missed a “evil’s code”, it could disable the firewall itself, then calling even more “evil’s code”
It needs to a) detect it running b) get an LPE or exploit to kick it down (hello? who said instant passworless root is ok?). So, basically, they run on close, but not similar privilege levels and it totally makes sense.
IMO, a security measure doesn’t have to answer or solve all security concerns. This specific measure (as I see it) should help detect unusual or unexpected traffic and also block any traffic that is already-known to the user but is unwanted, based on a rules created by the user. The firewall policy from a broad logical view should look like:
- “Allowed traffic to be ignored” (ex: in this AppVM it is OK for firefox to reach out to that local subnet / IP Range / URL)
- “Blocked traffic to be ignored” (ex: I know this app is dialing-home to a specific URL/IP for regular updates but I don’t want it to)
- “Blocked traffic to notify about” (ex: this is the first time this app is doing this, WTF? or this is the first time I ever see this app, WTF?)
I agree with @arkenoi that the application-firewall run on close but not on similar privilege level. However, I totally agree with @ppc that if the “deciding part” of the firewall is sitting inside the AppVM the solution is much weaker.
Just a thought: maybe the architecture should be two-part. first part is installed in a separate Firewall-VM, where you set the rules and get the alerts from, while the second part is installed inside the AppVM so it can know which app is trying to go where. These two parts should be connected/tunneled so only something that was approved and went through the local side is allowed out through the firewall-VM side. This way, if any evil-code managed to knock-out the local side of the FW, the outer part won’t let the traffic through because it didn’t come through the tunnel AND it will alert the user that something is trying to bypass the rules. Set a strict and very specific rule-set once, and I think we get more than decent boost in security to the whole Qubes-OS.
2 Likes
I’ve seen some “gateway type” application firewalls (which serve the entire network) and every single one required a lot of dirty tricks to mark workstation traffic per process and per user to let the firewall distinguish one from another. It is doable but requires significant effort.
You’ll see that I said that passwordless root should be removed if
running opensnitch.
while the second part is installed inside the AppVM so it can know which app is trying to go where.
As an aside … when using minimal application specific templates with a 1-app-per-qube model, and then compartmentalizing “correctly” this is basically no issue. If all the qube contains are your domain-specific emails and Thunderbird it’s rather inconsequential which application tries to connect to the outside. Or think of a qube that contains the source for a single project, and editor and git. …
1 Like
These kind of scenario also allow you to configure firewall rules that have teeth to them. … like the mail qube only being able to connect to the mail server on POP and SMTP ports. Or the project qube to only be able to talk HTTPS to a range of IPs belonging to Github. This way even if your qube gets compromised, extraction is very much unlikely.
That’s really the genius of Qubes OS and I feel most people posting here haven’t really grasped that yet.
- trust the Qubes OS project / XEN virtualization (THIS is your residual risk)
- compartmentalize as much as feasible
- firewall as much as feasible, keep your valuable data offline whenever possible
- regular full backups of your data
… if you do the above an eventual compromise of your system doesn’t rise above a nuisance in the vast majority of cases.
@Sven As much as I respect your opinion, and although I agree with the four “rules” you mentioned, I think your conclusion is misleading for the following reasons:
A. Qubes-OS built-in firewall doesn’t really check for protocol, just for port number. which is meaningless because one can easily open outbound connection of any type (SSH etc.) using an allowed port as is daily being done by malware and hackers alike all over world on a daily basis. On a side note, since traffic on ports such as 443, 993, 587 etc. is expected to be encrypted, organizations without SSL-inspection in place will not check the actual data going through these ports anyway.
B. Following your Thunderbird example, assuming someone is not a high-risk target and use Thunderbird (or any other email client) for normal daily usage, such person would often need not only email protocols (SMTP/POP/IMAP) to a known email server but also http/s to the rest of the internet since we’re not in the 90’s anymore and most email messages today contain linkes to images reside somewhere outside. With a rule allowing for ANY traffic on port 443 to ANY destination, the firewall almost becomes a waste of resources. (I’ve seen end-users in big organizations open outgoing connections of all sorts through 443 without knowing anything about networks - they just know that adding 443 at the end let them out through the company firewall), which brings us to…
C. Make a firewall policy as strict and tailor-made as you will, if you aren’t notified about an app/code that tries to go OUT against your policy, you won’t catch it and it will continue to try until it succeeds. Some may claim that it isn’t the exact job of the “firewall” but I think that having log/monitor/alert capabilities in any product is just good practice and doesn’t change its’ label.
D. Regarding your “trust the Qubes OS project / XEN virtualization” - I believe in the “Trust and Verify” approach. Mistakes can happen, vulnerabilities were found in XEN in the past as well as in other well used packages in Linux in general (some were there for many years before they became general knowledge and got fixed).
Qubes-OS is a wonderful thing that combine these two (Linux & Virtualization), trying to create a more secure way of working and I’m a big fan, but compartmentalization isn’t always enough, the current built-in firewall is very (VERY) basic and without taking anything out of all the appreciation and respect I have to the people who make this all happen (yourself included), I would really love to see a more capable application firewall along the lines I suggested in my previous post.
Cheers 
1 Like
@redmind, I wrote about firewall rules limiting to a specific IP/range AND port. The IP/range being the more important part obviously.
If you are at all interested in security there is no way you can justify loading images or even scripts from the internet in your email client. If you need to view those images or run those scripts (why?) then do that in a disposable browser qube but not in your mail client/qube.
“Trust and Verify”
Cute. Audit the code much?
I would really love to see a more capable application firewall
It will be a lot of work to make this anything that goes beyond “security theater”. For starters the “application firewall” itself would need to run outside the qube obviously. The information which process is trying to open a connection would also need to be somehow gathered from dom0 by watching execution inside the qube (not sure that’s even possible). Because whatever code runs inside your qube, obviously cannot be trusted to tell the truth / not be compromised.
And then even if you get all this done: how do you deal with applications like curl, wget, git, ping for that matter … all of which can be used by any other process to exfiltrate data (slowly in case of ping, but never the less).
@Sven hey man, I’m not fighting with you 
and I’ve read what you wrote.
I don’t like declarations such as “If you are at all interested in security” since I think security is for everybody, not just “top-secret spy-masters” or “security freaks”, of which I’m neither.
I believe that information security has levels, or scale if you wish, to suite each users’ needs. I use Qubes-OS as my daily driver, am very interested in security but has my business needs. One of them is opening email messages sent by our business contacts etc.
It doesn’t mean that I don’t care about security, it means I have to try and increase my level of security while still enabling my work needs. After all, Information security is there to keep our information secured, not avoid having information at all, otherwise I would have turned off my computer and the problem is solved 
As for your jibe, I cannot audit the code because my area of expertise is on the IT/networking side so I can’t help with that.
What I meant is to “Trust” the code/coders but “Verify” what it does in terms of opening connections. But I think you already know that and just wanted to have some fun on my expense.
I agree that building such a thing is a lot of work, and what you describe is the same architecture I detailed in one of my previous posts here, but if enough of us think it is worth it then it can be done, either by the community or by one of the many security providers out there (who will most likely build such a thing for computers running Windows, which will help none of us).
As for applications like curl, wget ping… you’re absolutely right that they can and are being used for data exfiltration, however, there should be no business for them to access the internet from a AppVM running just Thunderbird. (granted, I here assume that Thunderbird itself doesn’t use them but never checked it so I may be incorrect in this). Still, it doesn’t lessen the huge advantages for such an application firewall on any other AppVM.
1 Like
No, but the ability to read the code opens up the whole world and there are people who do read this code. Hence, I not solely trust the developers, but in addition rely on the whole community, where anyone who finds a vulnerability could get famous by reporting it. In my opinion, it decreases the (still necessary) trust in developers quite a bit.
@redmind we are having a conversation and disagree in certain points. This used to be normal and welcomed. It’s the only way to find out if your own position is solid or if it falls down when tested.
I don’t like declarations such as “If you are at all interested in security” […] One of them is opening email messages sent by our business contacts etc.
I have the same requirements as you. That’s one of the main reasons I do not run mutt but Thunderbird: to see HTML emails that are sent to me, including embedded/attached images.
Loading images dynamically is a trick used to track when and how often you read a specific email or to reduce the mail size in case of bulk mail notifications. Never, not once has a customer sent me such an email. I won’t even talk about JavaScript, because I hope we agree that’s nuts!
So when you wrote “we’re not in the 90’s anymore” I called you out on it, because that’s not an argument in this context.
What I meant is to “Trust” the code/coders but “Verify” what it does in terms of opening connections. But I think you already know that and just wanted to have some fun on my expense.
You wrote: “Mistakes can happen, vulnerabilities were found in XEN in the past as well as in other well used packages in Linux in general (some were there for many years before they became general knowledge and got fixed).” Are you proposing to screen for vulnerabilities by watching outgoing connections?
So no, this was not to have “fun on your expense”. In the context of what you wrote in your point D, I think my reaction made a lot of sense.
the huge advantages for such an application firewall on any other AppVM.
What I understand you want when you write “application firewall” is to have an interactive pop-up in dom0 that basically says: “/usr/bin/thunderbird in qube ‘mail’ want to connect to 64.233.162.16:465 aka li-in-f16.1e100.net – allow or deny?”
- how do you know /usr/bin/thunderbird is what you think it is and was not compromised?
- will you store checksums / signatures to detect when binaries in qubes changed?
- how is user to know that “64.233.162.16:465 aka li-in-f16.1e100.net” is a valid representation of smtp.googlemail.com:465?
- will you ask every time or store the “allow” after it was given once?
The problem I am seeing with this is that you delegate the decision to the user at a random point in time with very little meaningful information. It’s easy to imagine someone just clicking “allow” especially if this dialog is a regular thing.
My objection to this is the philosophy behind it. Instead of making a determination once of “what does this qube need to connect to?” the user is asked to make these decisions all the time, out of context and with bad information. The whole feature only makes sense for qubes that run multiple applications and are used to connect to a wide variety of addresses. In my view those qubes should be disposable. But then I don’t need the firewall anymore?
the ability to read the code opens up the whole world and there are people who do read this code
No argument with that, I intent to become one of them at some point in the future.
I know and agree, but my business needs are apparently somewhat different from yours and my contacts, usually suppliers, often send updates, invitations, publications and promotions in a way that requires me to load images dynamically. I am aware of it, aware of who’s email I open, and not only that I don’t mind a supplier knowing I opened a specific email, sometimes it is beneficial to me to have them know I’m interested/alive/active/in-the-loop.
A point some people sometimes forget is that the user is responsible for knowing what is their business needs, and information security has to be as tight as possible around those needs. With that in mind, and as I’m well aware of the risks involved in emails, I’m looking to tighten my security measures around my need to open emails and use other applications and services. One such is compartmentalization, others can be backup systems and methods, gateway security, network segmentation, (etc.) and so I’d very much like to add to that arsenal an application firewall, mainly to alert me if something in the system starts acting differently than it usually does.
If we’re to think aloud into the design (maybe it’ll help someone one day):
I’d like a pop-up in dom0 that says: App-FW has an alert for you, come check the logs". Then I will click and see something similar to what you suggested, with the option to edit the rule before I simply “allow or deny” (“once” or “from now on”).
- I cannot know that /usr/bin/thunderbird wasn’t compromised but I assume that it is clean if it was just freshly installed, and will suspect it if such request comes out of the blue after I worked with it for a time, and this is exactly the function I need the AppFW for - creating doubt and suspicion when something unexpected happens so I have the chance to look further.
- I’d LOVE to have something that checks checksums / signatures, can you recommend something for me? (seriously!
)
I’m sure that you know that the answer is to check from a different machine/network/DNS server etc. I think what you’re really asking is how to mitigate that risk from inside the AppFW. I don’t expect this feature to be part of the AppFW, although it could be nice to have the AppFW check that and let the user know that “for the rest of the world” this IP doesn’t belong to that URL. Again, cute feature but not something I expect to be part of the AppFW.
Definitely leave it to the user to decide. The UX here should allow and help the user to get a tailor-made rule-set, and only the user knows what and where his applications need to go (remember, we’re not talking only Thunderbird here. Some apps are allowed access only to specific internal IP’s).
Also, I would like to remind that (again) we must trust the users to know and choose what is good for them - one may decide that each application deserve a separate AppVM, another may decide that since few different apps are used with the same material/data they belong in the same AppVM (say, LibreOffice and a PDF or graphic editor). App-FW will allow them to set different networking rules to each application.
This is indeed a common concern - where to draw the line between “giving them fish or allowing them to use a net”. Deciding for the users is easier than creating a highly customized solution to allow each user decide for themselves how and what they want it to do, but that is the reason I use Linux and not one of the two popular OS’s out there.
The user isn’t asked “all the time” but only on the first time, and whenever something has changed in the way an application is acting on the network (which shouldn’t change much, if at all). You decide how much effort (and code) you’d like to put into context and information you provide. If you want to be extra-nice you could offer a recommendation such as “Thunderbird is usually ok to access these servers and those ports” or “This is the first time Thunderbird is trying to connect this server”. If I’m not mistaken, application firewalls such as ZoneAlarm exist since the late 90’s so someone else already did some of the UX/UI legwork and/or mistakes so we can know what works and what not to repeat.
I moved to Qubes a few years ago and had a Windows machine as my daily driver for a very long time before that. I used application firewall for over 20 years so I’m speaking from experience in dealing with such alerts as you mention. When set properly, you’re only alerted when something really requires your attention. A user who doesn’t know the words IP/PORT/DNS/URL and isn’t interested in learning, shouldn’t be forced to enable an application firewall in the first place, but will most likely won’t pick Qubes-OS in the first place as well.
Most qubes run multiple application if you consider (as you yourself suggested) curl, ping, wget, etc. I would like to know if a qube is trying to wget something i didn’t ask for, or start creating “DNS traffic” (data exfiltration?) - wouldn’t you?
An application that communicate to a narrow variety of addresses will benefit from this even more, because it will then be much easier to spot a change in communication behavior. Firefox in its’ own AppVM that has the sole job of connecting to the bank is supposed to get to a very few URLs and should be blocked (preferably from outside the AppVM) from going anywhere else.
Those qubes indeed should be disposable but a disposable qube gets "cleaned’ only upon restart and enough damage can be done by the time you got there.
Same as with every tool, or security measure, to each their own. I believe in the added value of a properly application firewall setup and as I feel myself committed to using Qubes, I would love to see one in Qubes 
See the previous thread on “Intrustion Detectors in dom0: bad idea?”
tripwire, AIDE
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.