On Thu, Dec 31, 2020 at 05:35:53PM -0500, Demi M. Obenour wrote: > On 12/31/20 6:03 AM, David Kalnischkies wrote: > > On Wed, Dec 30, 2020 at 09:32:32PM -0500, Demi M. Obenour wrote: > > Similar, why only check the hash of the diff if we can and should also > > check the hash of the file it produced (potentially as an intermediate > > as its on disk storage is potentially again a compressed file). > > > > With that train of thought we can just use https and be done with it. > > > > > >> This is safe. If the method returns malicious data, libapt-pkg will > >> detect it. The hashing and writing can be performed in a background > >> thread, so there is very little performance penalty. > > > > God forbid that someone runs `sed -i -e 's#background thread#method#'` on > > this sentence. The word "thread" doesn't make it magically more secure, > > actually less as a thread has a lot of shared context. >
> What I meant is that the hashing and writing (which I consider to be > trusted) should happen in a separate process than downloading files > from the Internet. The code that does the hashing is in the trusted > computing base anyway, and the likelyhood of a vulnerability is (IMO) > very small. Well the design for that which I started implementing was: 1. After downloading, let every file be copied by the store method, such that it gets hashed by a independent method 2. Make the store method trusted and have an untrusted and a trusted partial directory, and then it copies from untrusted partial to trusted partial while verifying. I started implementing 1 for debs being downloaded - debs really being the only thing we download uncompressed so that's where we don't already pass it to two independent methods, so it was a good first step - but the tests failed and no matter how hard I tried I could not get them to pass, so I eventually had to move on. I came up with a second design whereby all methods run as root again and then fork and untrusted process to do the server communication / decompression, which I believe solves all issues too, but is probably even safer. I believe this also removes the need for fd passing, though arguably we're ready for that, and fd passing is a work item that is already on my work backlog. Might even need both. Arguably I did not get the chance to implement it, except for well, I think I did move the decompression bits into subprocesses for the store method and that worked out fine. Improvements there are definitely on my roadmap, but it needs time to work on them, and work on this is tough to sell - it's not a cool new feature, it's obscure hardening techniques while we're already way ahead of everyone else (not that I actually checked what other package managers do). I also want to re-enable seccomp sandboxing, but that thing is a huge mess. User installs new nss plugin, boom method crashes. Probably gotta make it return EINVAL instead. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
signature.asc
Description: PGP signature
