I’m currently working on implementing the Kerberos protocol in Qubes OS. So far, I’ve set up Kerberos in the Qube that I use for my work in the company. Now I’m wondering how I can further develop this concept to manage and utilize Kerberos tickets across different Qubes.
Specifically, I’m questioning whether it’s sensible or poses a security vulnerability to perform ticket authentication in dom0. How would a concept look where the Kerberos ticket is automatically retrieved upon booting the computer (after the password prompt)?
Has anyone here had experience with this or can provide recommendations on how to build such a setup? I’m particularly interested in how to adhere to the security principles of Qubes OS while achieving efficient ticket distribution.
I appreciate any suggestions or shared experiences!
The details are important, but maybe stating the obvious - Kerberos as you probably know is very complicated and open-ended- and the implementations reflect that. Kerberos implementations are very high risk
Setting aside security concerns for a moment, I’m not sure I can envision how Kerberos would be useful in dom0. Can you elaborate a little more on what you’re trying to accomplish with regard to dom0+krb? Why would dom0 need a kerberos ticket? This sounds like a job for sys-krbcc
I have to agree with @Churros on this one. Doing this sort of thing in dom0 is not only dangerous, it’s also unnecessary to achieve your desired functionality.
If you think about it, you’re not actually authenticating dom0 at all. It’s the qubes that are being authenticated, so there isn’t really any reason to include dom0 in it at all, which begs the question again:
Um…why…?
…I mean, unless you want the actual booting of the Qubes OS machine to be authenticated via Kerberos. And if that’s what you want, remember that this can also be done via a qube after the machine has been booted, and from inside a qube before the KDC grants a ticket…
I can see what it is that you’re trying to achieve, and I think it’s a really cool idea, it’s probably just a good idea to keep it out of dom0.
There are a few reasons for this:
dom0 is also kept in the dark in some respects, particularly when it comes to networking
dom0 would have a very different fingerprint to the qube that you’d be trying to authenticate, and in some cases, you might not actually want that fingerprint leaving your machine
qubes-split-krbs would be an interesting idea (with a potential for self-pwnage due to sloppy misconfiguration, though…)
@pentbox In any case, it’s definitely impressive what you have done, it’s got me curious, and it’s worth investigating
I totally agree that integrating Kerberos into dom0 isn’t the way to go—not just from a security standpoint but also because it’s more than I need. My initial thought was to skip setting up an extra VM for Kerberos tickets since dom0 is always running, and I was a bit concerned about the extra resources another VM might use.
Right now, I use two different Qubes for work: one called “work” and another called “meetings” (for Zoom, Jitsi, etc.). My main challenge is needing Kerberos authentication in both and finding an efficient way to manage the tickets across them.
Based on what you’ve suggested, I’m thinking about generating the Kerberos tickets in one Qube (like “work”) and securely passing them to other Qubes as needed. I’m considering using Qubes RPC to handle this inter-VM communication.
I’m also intrigued by the idea of setting up a “qubes-split-krbs,” similar to how Qubes OS handles Split GPG. This would involve creating a dedicated, minimal VM just for managing Kerberos tickets (let’s call it “krb-cred”). The idea is to centralize authentication in this secure VM and have my work-related Qubes (“work,” “meetings,” etc.) communicate with it via Qubes RPC. This way, the Kerberos tickets are stored and managed in one place, reducing redundancy and potentially boosting security by limiting exposure. Of course, this approach would need careful configuration to avoid any pitfalls that could compromise the system. I’m curious if anyone has tried something like this or can offer guidance on setting it up while sticking to Qubes OS security principles.
I’d really appreciate any further guidance or experiences you can share on this topic!
It’s interesting, actually. It has the same allure as “running something as root” does.
And I’m guessing that work won’t allow you to have more than one Kerberos ticket for generic “security reasons”
Yep, we’ve all been there
Qrexec will work very well for inter-qube communication on the same physical hardware.
Another way I could think of to get both your work and meetings qubes on the same Kerberos ticket would be to put it in a sys-krb (kind of like the principle of a sys-vpn).
work / meetings
↔
sys-krb
↔
sys-firewall
↔
sys-net
↔
/ / /
Work Stuff
↔
Kerberos Ticket
↔
Sanitizer
↔
Network Hardware
↔
The Internet
No limit on how many qubes could simultaneously use a single Kerberos ticket
Limit any parsing errors or vulnerabilities to sys-krb
Kerberos never ever interacts directly with your NIC
Would this work?
Side-note:
I could also see Kerberos being a very interesting way (of many, I’m sure) to facilitate Qubes Air communication and orchestration (when it’s been a lot more developed, of course). Just a thought
@alzer89 Thanks for your input. However, I have actually decided not to separate my meetings and my “normal” work Qube. Too often, I need to share my screen, and although it works reasonably well with qubes-video-companion, it’s still quite cumbersome.
I now have my Kerberos configuration only in the Qube where I work…
I find Qubes Air very interesting, but I think it will still be a while before we can use it…
This is a bit off-topic: The reason for my question is that I am currently working on my bachelor’s thesis, which is about evaluating whether Qubes can be a good operating system for use in a company. My conclusion after 1 month: Yes, it can
/ 
/ 
/ 