Hi Marie!
"GUI and data rendering are not toys."
Ok, maybe "toys" was not the best word. But from my point of view (attacker
side) GUIs are (usually) almost impossible to be secured due to it´s
complexity and so I tend to see real all life implementations as "toys"
that can be broken easily.
" In Qubes OS, the GUI is one
of the core features, and a lot of work goes into making it secure.
Control over the GUI allows presenting arbitrary forged information
to the user and forging arbitrary user input (...)"
Yes, I know Qubes OS, is my default OS for sensible stuff (best option
nowadays IMHO). Anyway, as you probably remember, I hacked Qubes last year
and forged information flowing from one VM to another VM:
"Qubes File transfer tamper"
https://www.youtube.com/watch?v=gcEq2hAvKSM
of course this has nothing to do with forging information i the GUI of Dom0
or GUI VM (i new versions of Qubes OS), but is shows how easy is to forge
information in a VM GUI. In the above example we have a file transfer
between 2 VMs whose content is forged in real time. Here the "hack" was
just a simulation where I artificially manipulated the file transfer
mechanism but it is enough to show that (nowadays) GUIs of standard OSs
can´t be trusted. No matter how much effort you put in there. If you harden
the file transfer, then the file can be manipulated at the end point,
either its contents or either it´s presentation (I hope no one dares to
"prove" security of Xorg or any other common X window system... it is
impossible that humans deal with such monsters). So, what the end user
"sees" in the screen nowadays is just a joke as everything can be
manipulated.
As far I have learned, if you want to secure what humans "see" in a screen,
then you need a very simple presentation schema. When you go for complex
representations of information then the game is over because no matter how
much you protect the source and the channel, whenever the information is
processed in a non verified big OS then there are many ways to forge
information because the are many bugs in such big OS that can be exploited.
The easiest way explain this is: figure out how you can secure rendering
software for: PDFs, docs in all its formats..., images, videos,.... too
many people in the party so it becomes impossible. I can accept that you
can try to build a "secure Linux GUI system" where, in example, you just
set up kernel + Xorg + your own PDF renderer/"transformer" (transforming to
image is becoming a trend). Anyway, even in such ideal system, still kernel
and Xorg are out of your control and I hope you don´t user tcp/ip stack for
nothing and just build your own VMs transfer mechanism (like in Qubes OS).
"Imagine a security system saying that the system was armed when it
really was not, or a control station saying that everything is fine
when something is about to explode."
I would never use a generic OS with a a generic software/interface to video
output to say "system is armed", instead I would make it as simple as
possible. In example red/green light activated via GPIO.
El mié, 19 oct 2022 a las 1:34, Demi Marie Obenour (
On 10/18/22 18:09, Hugo V.C. wrote:
"So I'm interested in sel4 as I could run the processes in Linux VMs"
Sure, you can do it, but then the Linux Kernel becomes the weakest point and you have little or no control over it.
Ideally, I would not pass any sensible data flow to Linux, more over if there's any potential interaction with humans or something that can be manipulated by humans in any way. Any. Instead, use seL4 native app to do the sensible job and just use Linux for the "toys" (GUI, data rendering to human format, etc).
GUI and data rendering are not toys. In Qubes OS, the GUI is one of the core features, and a lot of work goes into making it secure. Control over the GUI allows presenting arbitrary forged information to the user and forging arbitrary user input (either directly or by tricking the user into entering it). This is a tremendous amount of control, and is often nearly equivalent to complete system compromise. Imagine a security system saying that the system was armed when it really was not, or a control station saying that everything is fine when something is about to explode.
In my security designs I do all sensible stuff in native seL4 apps then I have an spartan and very controlled interface with Linux VM. Don't let Linux handle sensible data flows... If you are dealing with humans, your options are either to give Linux control over the GUI or implement the entire GUI natively on seL4. If you choose the first route, you cannot prevent the Linux VM from being in a privileged position, but you can* make it very, *very* hard to attack. -- Sincerely, Demi Marie Obenour (she/her/hers)