qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<MichaelRaskin> Hm. I am not sure — is there any document online with Spectrum goal list on a more detailed level than a very generic overview?
<MichaelRaskin> I might be interested to use (parts of) Spectrum, and in any case I could try to use my experience with all-Firefox/LibreOffice-must-be-in-nsjail etc. to improve it
<MichaelRaskin> (I also run most of the PDF viewers in nsjail by now; also everything needing audio output; so I have some use-case experience)
<qyliss> Not yet, but improving the overview and stuff are very high on my to do list.
<qyliss> I just got the final sign-off for funding yesterday, fwiw.
<MichaelRaskin> Oh cool, congratulations!
<MichaelRaskin> (a discussion venue about the goal list would also count as an answer to my question, by the way)
<lejonet> qyliss: Congratulations
<qyliss> MichaelRaskin: we have mailing lists! Although I'm still tweaking the configuration, so not promoting them too heavily yet.
<qyliss> MichaelRaskin: https://spectrum-os.org/lists
<MichaelRaskin> Yes, I saw there is nothing about mailing list on the page that mentioned IRC and assumed they are not yet set up
<qyliss> They are mostly set up
<qyliss> And there are people subscribed to them
<qyliss> (I posted them in here before)
<qyliss> But I'm not quite ready to shout about them yet.
<qyliss> Want to set up public-inbox first.
<MichaelRaskin> Here maybe, I have only put at my idling bot here recently
<qyliss> I've been working on a NixOS module for public-inbox for the past couple of weeks
<MichaelRaskin> I don't see a subscribe link in the list info…
<qyliss> yeah it's a weird ui
<qyliss> You can also mail discuss-subscribe@spectrum-os.org, I believe.
<qyliss> (and the same for announce and devel)
<MichaelRaskin> Yes, it works, thanks
<MichaelRaskin> (At least I managed to reach the «Welcome to the list email» stage)
<qyliss> :)
<qyliss> MichaelRaskin: this might be useful for you as some background on the current direction of the project btw https://alyssa.is/back-from-cccamp-2019/
<MichaelRaskin> After having read the post, I am more or less sure I had read this in the past
<MichaelRaskin> (Moreover, this post is probably how I found out about #spectrum)
<qyliss> Aha, okay
<MichaelRaskin> Currently, I obviously have some amount of value misalignment with SpectrumOS (but I don't believe in using tools as intended anyway, so hopefully I can get and provide some value somewhere)
<MichaelRaskin> BTW re: TALOS builders — you have read the complaints about Raptor, like De Vault's one?
<qyliss> Yeah
<qyliss> Seems like they've pretty much been addressed with the new RTM flow.
<MichaelRaskin> It will take time to see how much it helped…
<MichaelRaskin> (not saying getting them is definitely a bad idea, of course — more like «one has to budget quite a bit of time and effort to get started»)
<qyliss> Yeah, that's accounted for in the plain.
<qyliss> s/plain/plan/
<MichaelRaskin> Depending on threat model, the Raptors you order are way easier to track than a handful of Allwiner boards you buy from a noname reseller… (generic backdoors are not really optimised for attacking custom Qemu builds — that's an expensive task, after all)
<hyperfekt> hi to the nsa agent reading this o/
<MichaelRaskin> You wanted to say contractor, right?
<qyliss> That is very true, but I think that it is outweighed by being able to modify / use known good versions of all the firmware and stuff that I can only do on the talos
<MichaelRaskin> Well, the builders need pretty filtered internet access (HTTPS proxy might be enough in practice), so the main risks from bad firmware might be much less acute
<MichaelRaskin> You cannot easily verify chip identities in a Talos anyway
<MichaelRaskin> BTW, is the ultimate provenance enforcement measure planned for most tightly-controlled VMs in Spectrum?
<MichaelRaskin> I mean permuting the system call numbers — this guarantees that everything that still works is specially built for this, and also hidden binary blobs will crash, and also RCE shellcode will also probably crash
l33 has joined #spectrum
<l33> hi!
<MichaelRaskin> Hello
<l33> i'n quite interested in spectrum...
<l33> :-)
<pie_> MichaelRaskin: o/
<MichaelRaskin> Hello pie_
<pie_> oh huh never heard of permuting syscalls, cute.
<pie_> is there a sufficiently large number of interesting syscalls, can it be proven that a bad binary will crash
<pie_> or is it deemed infeasible at this point for someone to expect permuted syscalls
<pie_> :D
<pie_> s/infeasible/not worth it/
<MichaelRaskin> Well, unused syscall slots can be aliased to exit, you know
<MichaelRaskin> That's the point, actually — there is a ton of syscall slots, and we only need a few of them to be survivable
<MichaelRaskin> I think our linuxHeaders list ~500 syscalls. That means well-tested support for two-byte syscall numbers (at least 32768 options, whatever one messes up!) with around 600 survivable slots (that's before seccomp)
<MichaelRaskin> I think not everyone can afford the toolchain to shuffle the syscalls. Nix and OpenWRT definitely can, but for some approaches it might be a bit too expensive
l33 has quit [Remote host closed the connection]
l33 has joined #spectrum
l33 has quit [Ping timeout: 246 seconds]
<pie_> MichaelRaskin: i was thininking along the lines of, what if you can just run some probe processes to figure out the right ones
<pie_> or does that require some preconceved notion of e.g. being able to poke the appropriate part of memory,etc
<pie_> well i guess its much easier to handwave than not