"I think my use case the system gets reset (read only os) on every use and
a typical use time is perhaps a few minutes."
Nice. Read only systems are better than those who allow permanent changes.
Anyway (and excuse me, I really don´t want to look pedant) from attackers
point of view, this is almost irrelevant. Moreover, those read only systems
are usually perfect systems for exploits as are static so debug and
development of exploits is easier than dynamic systems. I mean, I agree
read only is better than writable as every reboot is a new clean
environment. Anyway.... when you plan an attack (talking from my own
experience) if you have a read only static system then you know you need to
create a one shot exploit or chain-exploit "fire and forget"... that is, it
must autonomously and blindly work and in the time windows you have. Here
the time window is the critical point and every scenario will be
different. Again, anyway, in computing "few minutes" is an entire life...
unless the attacker plans to steal 100GB of data, leaking documents can be
done in a matter of seconds. Remember an exploit is not a VNC/RDP where
attacker do things manually, it is code that runst as fast as CPU allows,
so if the attack is targeted and well planned, minutes are a glorious
amount of time (in the past I´ve been fighting in terms of milliseconds in
some race conditions exploits....). I just give you some information and
excuse me in advance if I misunderstood some details of your specific
environment, it is difficult to evaluate stuff in a so generic explanation.
"In terms of minimising the impact of comprimise I'm thinking of using
three VMs - insecure/comprimise exposed, a "between states" VM which would
enforce data flow syntax/packet checking between the other two VMs, and a
secure/trusted VM."
Without details of the implementation I can´t say too much about this even
if I guess that what you are trying sounds good. It all depends on the
design... My only advice is to get as much info you can from offensive
profiles, think out of the box, minimize the attack surface and makes
things as simple as possible. And if things must be ugly to be secure then
make them ugly.
El mié, 19 oct 2022 a las 10:00,
" So I was assuming the isolation between VMs are more assured using sel4."
Yes. isolation is what is guaranteed and proved by seL4. This is the "magic" of having it´s code formally verified and what makes the difference with any other solution, in terms of isolation.
"In itself I am not worried if the VM is compromised."
Then go ahead. But remember that if VM is compromised then the solution is compromised. So if you need to sell/distribute this solution you will need to argue to your customers/users why you don´t care about VM compromise...
"Perhaps I could get usb stack ported natively... "
Anything you strip down from the VMs and port it to native code you get a giant improvement in terms of security.
El mié, 19 oct 2022 a las 7:54, <james.hillman07(a)gmail.com> escribió:
Hugo V.C. wrote: "My intention was to use a minimum image with no UI but importantly the USB drivers/stack."
Sure. This is a common approach and default VMs examples of seL4 tutorials are exactly that: a kernel + busybox, so no UI. Still this is just Linux with a very big kernel...
El mié., 19 oct. 2022 6:37, <james.hillman07(a)gmail.com> escribió:
Thanks everyone, really enjoy reading the discussion. Sorry for the lazy untargetted use of the word Linux. My intention was to use a minimum image with no UI but importantly the USB drivers/stack.
I guess the key issue is what the best data rate I could hope for between the VMs. _______________________________________________ Devel mailing list -- devel(a)sel4.systems To unsubscribe send an email to devel-leave(a)sel4.systems
So I was assuming the isolation between VMs are more assured using sel4. In itself I am not worried if the VM is compromised. Perhaps I could get usb stack ported natively... _______________________________________________ Devel mailing list -- devel(a)sel4.systems To unsubscribe send an email to devel-leave(a)sel4.systems
Thanks for confirming and continuing the discussion. I think my use case
Hugo V.C. wrote: the system gets reset (read only os) on every use and a typical use time is perhaps a few minutes. In terms of minimising the impact of comprimise I'm thinking of using three VMs - insecure/comprimise exposed, a "between states" VM which would enforce data flow syntax/packet checking between the other two VMs, and a secure/trusted VM. _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems