1. 29
  1.  

  2. 1

    It seems like lots of these hoops can be removed when openbsd implements the pledge directory whitelist feature. Can anyone elaborate as to why that feature was added to the function signature, but not implemented for such a long time?

    1. 7

      Changing the prototype for a function, especially a syscall, is involved and annoying. Adding the extra argument let us play with the implementation a bit without constantly changing code everywhere. The whitelist plan is taking longer than expected to come together, and it’s probably going to look a little different in final form.

      1. 1

        Thanks, I wondered if it was performance issues that hadn’t been resolved. It’s a feature I’m looking forward to.

        1. 4

          Making sure it can’t be abused as a performance bottleneck is also part of it.

          The feature came about in part because I wanted to sandbox Firefox. The objective is to prevent Firefox from reading my .ssh directory, or my maildir, and uploading it to some rogue site. But sometimes people like uploading files on purpose. So we’d whitelist the ~/uploads directory or something. But some open questions are things like do we kill the whole browser just because somebody clicked the wrong file? How do users know which files can be uploaded and which can’t? So that stalled a bit. At least for that design, we knew it would work for Firefox, but the problem was really at the other end. What does the feature look like at the frontend of Firefox?

          There weren’t a lot of use cases in base. For the most part, base utilities can do a pure privdrop approach. Some exceptions can use a privsep approach instead. It was hard to make a list of exactly which programs would benefit from any given design.

          1. 4

            Are you trying to sandbox the content process, or the parent process as well? Our goal (which will be mostly realized for Firefox 56) is that the content process shouldn’t need access to any of the filesystem (modulo its own resources directory and a few other things), when it needs to do something like upload a file for an <input type="file"> that’s orchestrated by the parent process.

            If you’re interested in chatting more about how OpenBSD’s pledge could fit into the existing sandbox architecture, feel free to reach out (work email in my profile).

            1. 2

              Well, I’m off team sandbox for now, but the general outline is to orchestrate everything in the parent. That generally works well with pledge, with fd passing.

            2. 2

              Could there be, say, a separate process for only the file selection window, which passes a file descriptor for the chosen file over a Unix socket to the main sandboxed process?

              Or maybe the file opener actually reads the file and passes raw bytes to the main sandboxed process?

              1. 3

                You can do that, although in the case of a browser some extra precautions are needed as well. I want to stop the browser from uploading my files. But the browser also uploads files deliberately. So whether it’s in the render process or somewhere else, there exists code for the purpose of file uploading.

                In theory, there could be a whitelist in the browser. Only allow files in these directories to be uploaded. But such whitelists, much like the same origin policy, are subject to bypass and confusion. And we could say that files can only be uploaded in response to user action. But there’s this whole javascript runtime dedicated to creating fake events that look a lot like user action.

                The concern isn’t just that there’s a buffer overflow in some image library or whatever. The purposefully written and existing upload code might be activated against our wishes as well. This was in the time of the pdf.js vuln. Actually, the original pledge (nee tame) whitelist code was added two weeks after this. https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/

                1. 2

                  I was thinking more:

                  • the browser process doesn’t have the ability to open a file to upload it,
                  • but it does have the ability to pop an ‘upload a file?’ window
                  • and the ‘upload a file?’ window will open a file iff you, the user, pick one
                  • and the ‘upload a file?’ window can send those bytes to the browser

                  so now for a miscreant to upload your files requires suborning the ‘upload a file’ program via the browser, which could be more difficult because it could have a quite small attack surface exposed to the browser process

                2. 1

                  this definitely seems like the “clean” solution, but wouldn’t that involve working on the GUI toolkits involved?

                3. 1

                  I see, I wanted it to allow my programs to freely read and write a database, config files and logs in a specific directory but nothing else. Firefox is definitely an interesting use case.

                  1. 1

                    But some open questions are things like do we kill the whole browser just because somebody clicked the wrong file?

                    Seems like the right answer is namespaces. You can’t click on the wrong file if it isn’t listed.

              2. 1

                It wouldn’t help. As mentioned, SQLite makes no guarantee as to which files are going to be used between versions of SQLite. You can guess, but sometimes a file only pops up in response to a given workload, or a given database mode (which can change, like switching to WAL, during run-time). One possibility is to white-list all possible files. But of course, then the developer must tie an application to a particular version of SQLite. And of course, one can also direct SQLite to change the directory in which some of these files live.

                …hence the hoops.

                1. 1

                  But you could whitelist a directory

              3. 1

                Serious question: isn’t it super scary to run “real” things on SQLite? Or are things like backup tools also well developed for SQLite at a “reasonable load”.

                1. 5

                  Depends on how real you want to get. As a backup strategy, copying a file works pretty reliably and isn’t subject to bugs in the replication log or whatever. Easy to verify the copy is correct, too.

                  1. 3

                    I don’t know why it would be.

                    It’s unusual for web applications, since they have to setup servers and all of that anyway, but SQLite is used by a ton of standalone applications.

                    1. 2

                      It is the most used sql db on the planet, why would that be scary?

                      1. 2

                        The test suite is quite substantial as well.