<IdleBot_b5116448>
Just got a broadcast notification on a @(non)gnu.org mailing list that GNU mailing list policy is now Sender:, List-Id: and unmodified message with preserved DKIM
<jpo_>
batch-processing backlog, sorry for oncoming bulk-replies:
<qyliss>
Hi jpo_!
<jpo_>
MichaelRaskin: permuting syscall numbers does not stop attacks, you just need an to add another infoleak to your chain that discloses syscall #s, but these are found at e.g. known offsets in libc. high negative impact to usability, low impact to security. no thanks
<jpo>
tl;dr - their threat model needs refinement, but it seems mostly sane
<jpo>
DrWhax: woah, pH is new since last i looked. that's looks pretty interesting. last i looked at subgraph it was clear that they were still doing things, but seemed kinda weird, and I couldn't find any docs on high-level design goals since grsec went closed. are you aware of any such design docs?
<jpo>
pie_: there actually was some research project that permuted the instruction set on the fly as a security-by-obscurity thing. seemed fairly academic, and unfortunately i don't remember what it was called
<jpo>
re ME: I've come to believe that intel isn't inherently evil or actively against open stuff, they've just made bad choices in the past and have economic realities which propagate bad design. at some point they added the ME because... well... because they don't talk to their customers enough before deciding what would be a desirable way to implement things
<jpo>
and they when implementing other functionality later which needed to have e.g. trusted I/O paths to peripherals, they said "oh hey, we have this other microcontroller over there on the PCH, and it's always there, we might as well throw this functionality in it too"
<jpo>
and as such, it continued to grow
<jpo>
and now they're in a position where even if they wanted to get rid of the ME (and there are indications that they do and seem to be making efforts in that direction), it's just an actually non-trivial engineering problem to decouple the big ball of shit now while nominally preserving all their backwards compatability obligations
<jpo>
"evil and poweful forces keeping them actively hostile to trustworthy platforms" or something really doesn't seem to be the most probable explanation of the current situation from my perspective
<jpo>
(as much as i love a good intel conspiracy theory)
<DrWhax>
jpo: not sure about any design docs
pie_ has joined #spectrum
<jpo>
edef: qyliss: wait, what's this about xpra and xephyr? nested-X is not sufficient X isolation. it's a complex protocol with a complex backend, and if you have an exploit against the X server (of which there are probably several), it'd probably chain just fine right through either. plus, from a performance perspective, you probably want some zero-copy shared-memory rendering thing anyway, and you really want that protocol as simple as possible (read: definitely
<jpo>
also what chromiumos has done with virtio-wayland looked pretty interesting (and from the bit i looked at a while ago IIRC seemed fairly sane)
<jpo>
lots more thoughts on this topic if you search the qubes-devel archives
<jpo>
(also interesting considerations such as difficulty of integration with other OSes, retrospectives on how qubes' design has rather remarkably avoided a lot of otherwise necessary guest-driver maintenance, etc.)
<edef>
jpo: xephyr renders to a buffer
<edef>
jpo: it would be quite feasible to separate the render-to-buffer and the X client
<edef>
jpo: like, it renders to a shared-memory XImage
<jpo>
but the same process is both an X server and X client to the trusted top-level X server, and if you have a bug in the X-server protocol, it not-unlikely chains for free, rendering the overall design less than ideal
<edef>
i understand that
<jpo>
and if you replace the upper protocol with something simpler, then it's essentially running an X server with a different backend anyway
<edef>
i'm saying the diff from single-process Xephyr to multiprocess Xephyr wouldn't be huge
<edef>
i am not saying that Xephyr, as it exists today, is satisfactory
<jpo>
err, what are you proposing exactly?
<jpo>
qyliss: that's a pretty sweet way of splitting the git metadata/work dirs. i've done similar stuff w/ hooks in gitolite, but i like how simple yours is
<qyliss>
:) I was quite proud
<jpo>
re "and maybe provide templates that make fingerprinting among default SpectrumOS Firefox setings more complicated, too": don't bother. if you want that, just ship TBB and focus time on actual OS stuff instead of browser config maintenance
<jpo>
different projects have different core competencies. leveraging existing community efforts can make a lot of sense
<jpo>
(subject to the different project's security stances and impact to your TCB)
<jpo>
re crosvm vs. kvmtool: yes, quite different. crosvm has a bunch of desktop-integration oriented stuff and is written in rust, kvmtool does not and is written in C
<jpo>
lejonet: re "take the pipe part of veth pairs without needing the networking above it": yes, you're looking for vchan/vsock/v4v/argo
<jpo>
re passing around block devices as a transport for files between different trust boundaries: this is what Qubes did initially and turned out to not actually be a good idea, and is what motivated the creation of qubes' as-simple-as-possible-for-the-use-case file container format (qfile -- think kinda like cpio) and pass these blobs around over essentially sockets
<jpo>
you don't want block devices for a number of reasons: you don't want to allow a less-trusted domain to exercise the probably-not-defensively-written filesystem-parsing code of a more-trusted domain. filesystem compat is not actually a trivial problem if you care about more than just linux. also the encoding/decoding is more expensive, and the easiest way to implement it (loopback mounts) is not efficient for overall time taken to xfer a single small file (high
<jpo>
also, in the case of large files, in the block device case you probably end up needing another intermediate copy at least in ram, whereas in the trivial file container format it is possible to just send its header and then stream the contents
<jpo>
as for external storage: you shouldn't trust external devices, so any direct propagation of the external (read: attacker-controlled) device into trusted contexts is undesirable. a much safer approach is to isolate it and have strict copy-in/out using the same mechanism as above
<qyliss>
jpo: huh, so you didn't recommend block devices to me at camp?
<qyliss>
wonder how I came away with that impression, lol
<jpo>
yes, i definitely did, but in a different context
<jpo>
i'm getting there, lol
<jpo>
(going through backlog semi-chronologically)
tilpner has quit [Quit: tilpner]
tilpner has joined #spectrum
<IdleBot_b5116448>
Re: TBB as a source of Firefox profile: I agree it is a good source, and we would probably need some wrapping code around all this to launch multiple instances in a more efficient way (my experience says, that given a Firefox config cloning a prepopulated profile is much faster than letting FF bootstrap it every time)
<IdleBot_b5116448>
Re: external devices: of course mounting them should be in a separate VM. Copy-in-copy-out is _often_ the best option, but sometimes it is very desirable performance wise to share a mount without an extra copy. Is an unreliable 9P server much more dangerous than a 9P client?
<qyliss>
pie_ ehmry: gonna do a Spectrum meetup or whatever tomorrow after talks when everybody is going to pub and stuff
<lejonet>
qyliss: where are you planning to have it?
<qyliss>
lejonet: no plan yet
<lejonet>
qyliss: okidoki, I'd be interested to attend, but I assume once you've figure that out, you'll post it in this channel?