mixedbit

In cases where you need agents to fetch data from any remote source, sandboxing is still very much useful. Why give access to your ssh keys to network reaching agents?

Look at websites: websites are able to fetch code from any remote URL, yet browsers heavily use sandboxing to ensure that if fetched code turns out to be malicious, the users local files, cookies, etc are not exposed.

An agent doesn't inherently need wide access to be useful. The most popular application for agents today is writing code. A coding agent needs write access to the source code and read/execute access to tools needed to build and test the code, but not much more. There is little added utility from giving coding agent access to things like ssh keys.

Or perhaps this is a new reality where for each current problem we will see myriad solutions because of how easy it is to put together a prototype with agents. 3 years ago having a sandbox was also an important problem to address, but we didn't see so many attempts.

gVisor has performance benchmarks: https://gvisor.dev/docs/architecture_guide/performance/ Long ago I worked on and benchmarked a Linux user space virtual filesystem that used ptrace to intercept and amend system calls. For surprisingly many workloads, per system call performance overhead is negligible. This is because many programs either wait for IO, in which case the small added overhead of a system call doesn't really matter, or spend time on CPU doing some computation. Only workloads where kernel is hit with long series of syscalls have measurable performance overhead. The difference is visible in benchmarks, but not anything that a user is able to notice in an interactive shell session.

An interesting book "Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon" describes how the researchers at Symantec who analyzed Stuxnet ran malware:

"They worked in Symantec’s Threat Intelligence Lab in Culver City, the cyber equivalent of a biodefense lab, where researchers could unleash malevolent code on a “red” network—a sandboxed system air-gapped from Symantec’s business network—to observe its hostile behavior in a controlled environment. To reach the ground-floor lab, workers passed through several sets of security doors, each with progressively more restrictive rules. The final gateway kept all but a handful of workers out and physically isolated the red network from computers connected to the outside internet. Portable media were prohibited here—no DVDs, CD-ROMs, or USB flash drives were allowed —to prevent workers from mindlessly slipping one into an infested machine and inadvertently carrying it out of the lab with a malicious specimen stowed away on it."

Per syscall performance overhead has surprisingly low impact on overall performance of programs. gVisor's benchmarks are here: https://gvisor.dev/docs/architecture_guide/performance/

No, I haven't tried it, thanks for the pointer. It looks like something that could be used by Drop instead of Linux namespaces. I didn't yet encounter any obvious limitation of the namespaces (other that some distros, like Ubuntu, are keeping programs' access to the user namespace creation behind AppArmor allowlist, which makes the Drop installation more involved).

Unfortunately not, and it also does not support starting containers from the sandbox.

I mean, Drop does mount host filesystem in the guest, the idea is that you keep working within your current distro and have access to some of its files.

Thanks! I have GUI applications sandboxing on the roadmap. I also ponder the idea to add VM as the third runtime option (in addition to currently supported native Linux namespaces and gVisor). I'm not yet sure if this is feasible, but VM could allow to start containerized apps within the sandbox as it dodges the nested namespaces problems with containers.

This table shows which dirs are exposed from your system: https://droprun.sh/docs/sandbox-overview/#filesystem-layout

Compared to your setup:

* /usr is from your host, so you don't need to maintain a separate image to have programs that you already have installed.

* username, hostname, your current directory and home dir paths are preserved in the sandbox (within a Podman container a home dir is /root)

* environment variables are easy to carry into the sandbox.

* environments are explicit (`drop ls` lists them) and can be removed with `drop rm`, so you don't need to track in which dirs you have started Podman if you want to cleanup XDG_HOME files.

It is likely that your Podman wrapper also solves some of these or they are non-issues for your. If your setup works well, I wouldn't switch to something different.

> As the container escapes with K8s shows, it is super tricky to get isolation right. E.g. what happens if a file you think is safe to write to is suddenly is replaced by one that isn’t.

I agree. One thing I'm doing is to review past security problems in popular sandbox and container related projects and check if they apply to Drop. Drop is also rootless only (it won't even start as root), which helps to cut some classes of problems.

My approach with Drop was to start from designing a sandbox user experience. The key idea was to preserve as many aspects of the user's work environment as possible while isolating things that need to be isolated. So keeping the user's distro with all the currently installed packages is the key thing for Drop.

The first Drop version (and the current default runtime) uses Linux namespaces alone to achieve this.

Then, gVisor was added as the second runtime, because it could be done in a way which is completely seamless from the user perspective, both runtimes produce identically looking sandboxes.

A lightweight VM could potentially be a third runtime, but I'm not yet sure it is possible to use a VM in such a way, that the sandbox is configured identically to the first two runtimes. Basically, quickly boot a kernel using the distro already in / and mount the same dirs Drop mounts with two other runtimes. An obvious problem I can already see is that /etc is not fully readable to the user running Drop, so using it to boot a VM will require working around lack of config file access.

Anyway, if VM support was possible, it would obviously have advantage of being fully compatible standard Linux kernel while providing very good isolation of the host kernel. gVisor does have some compatibility issue, as it is re-implementation of the kernel in Go.

Another advantage would be that with VM runtime it would be possible to start containers from Drop, which currently, due to issues related to nested namespaces, is not supported.

read-only everywhere and write only to the current directory is good if you want to prevent accidental damage, such as a coding agent could make if it hallucinated an invalid command, like `rm -rf ~`.

If you want to prevent a damage from a malicious dependency or a prompt injection, you need more robust protection (for example read-only everywhere exposes your ssh keys). You can build this on top of bwrap, but because it is a low level sandbox building block, you would likely end up creating some higher level abstraction on top of bwrap (for example srt and Flatpak are build on top of bwrap).

Drop is an attempt to create such a generic, high level sandboxing tool. I personally prefer to run agents already within a sandbox than to rely on a coding agent runtime to sandbox itself. Especially that by doing so, I can use the same sandboxing tool and config for installing other programs that need isolation, not just for running agents.

Thanks! My initial approach and the first prototype was for Drop to be a Python script that generates config.json file for runc Docker runtime (I also tried crun). I ran into issues that prevented the sandbox from being set up with all the Drop-required properties. These issues were certainly technically fixable, but it could be difficult for a new project with no usage to advocate for features in mature and widely adopted tools. Especially that runc and crun are OCI-compatible Container Runtimes, and Drop is not an OCI-compatible container, so it could be justifiably out of scope for these projects not to support Drop usage.

Anyway, my decision, for which I also evaluated the use of bubblewrap as a building block, was to err on the side of flexibility that calling fine-grained Linux APIs directly give. For a project like Drop, runc could be seen as very coarse-grained JSON-based API to Linux sandboxing calls (basically a single call: setup a sandbox, here is a json config that describes it), similarly bubblewrap is a coarse grained command-line API to Linux sandboxing calls. Reusing such tried and proved layers of course also has significant advantages, so as in case of many engineering decision, it wasn't super obvious which path is better.

Drop eventually integrated gVisor's runsc (as an option), which is also OCI-compatible Container Runtime, but this is to add a user-space kernel isolation layer.

Bubblewrap is a low level tool, it describes itself as a sandbox building block, rather than a high-level sandbox intended to be used directly (for example, Flatpak uses bubblewrap as its building block). Drop in contrast is high-level, designed to be used directly in day-to-day work without the need to assemble the low-level details of the sandbox.

In traditional software development process two artifacts are created. The obvious one is software. The second, is knowledge of the problem domain in the development team heads.

We could take the Hofstadter idea and say that there is an isomorphism between these two artifacts. Software is a manifestation of the team's knowledge the way an organism is a manifestation of a genome.

With AI, the second artifact is no longer necessarily produced. We don't need to have a team that, as the project progresses, slowly becomes a group of domain experts. Experts that can drive the project direction. Experts that, with time, can see the flaws in their first project and start new breakthrough projects to fix these flaws.

During the Covid global chip shortage Intel announced new factories to address the production bottleneck, before the factories even started to be constructed, the shortage was long over and the projects were eventually canceled.

The unfortunate true is that getting even the best work in front of an audience is often much harder than solving the problem. Is uploading a paper to arXiv enough to expect the work to be recognized and cited? Unfortunately, it rather is not. arXiv is an open repository which includes plenty of not reviewed and not officially published papers. In a popular field such as machine learning, the number of arXiv papers is overwhelming. Expecting that some machine learning expert will stumble upon an arXiv paper and recognize its value is wishful thinking.

I'm not a researcher, but long time ago I had an idea of a new, seemingly interesting attack on TCP. Having some free time between jobs, I wrote a paper about this, created a proof of concept and decided to send the paper to USENIX Security. I got back two reviews, both in rather positive tone, but rejecting the paper on the grounds that it shows only individual steps of the attack, but it would be much stronger if it showed also the attack working end-to-end. At that point I just uploaded the paper to arXiv and called it a day. I've put a lot of work into that paper, but not enough, I don't consider it properly published and I don't expect anyone to cite it. The paper failed the peer review process and I didn't put the work to improve it further.

This assumes that a known watermarking algorithm is implemented. To me, unless output starts to include information whether watermark was inserted or not to a result, relaying on such an assumption is risky. If a human editor needed to hide a secret bit of information in the edits, this would certainly be possible even if the edits were small compared to the length of the original texts.

I'm afraid watermarking could restrict applications where LLMs can be safely used to assist with writing. If I write something myself and use an LLM to proofread it, without watermarking I can confidently say that corrections done by LLMs are small and insignificant enough to claim that the text is still authored by me, not by the model. With watermarking, however, I will never be sure if the result will not be flagged as AI generated, even if the AI contribution is very minor.

My experience with Boto: need some S3 manipulation logic, here is an official documentation that shows how to solve the exact problem with Boto, one caveat, this version of Boto is deprecated. Do the same with the newest version? Not possible.

Apple stock is up 18% in 2026

It assembles and pivots to own root filesystem. The filesystem mounts dirs and files from your original filesystem, most of them in read-only mode, but does not mount files that expose secrets to the sandbox. The sandbox also mounts own, writable version of your home dir, so secrets, such as .ssh dir are not exposed. The config file allows to configure which files should be exposed from your original home. For example, configs, such as .bashrc, are safe to expose in read-only mode, provided you don't store secrets in them.

I work on a sandbox which has similar isolation level to Podman (rootless Linux user namespaces), but with UX optimized for local development work. Take a look: https://github.com/wrr/drop Basically, you don't enter a separate container in which you install a new distro, but you run on top of your current distro. You have environment specific home dirs which isolate your original home, but can have some files, such as configs, mounted from your original home (mostly in read-only mode).

Normal vending machine transactions are B2C transactions, so the buyer cannot be a company - cannot pay with company money and cannot deduce the payment as the company cost. I guess, the buyer can take a receipt from a vending machine and ask the vending machine owner to provide a B2B invoice based on the receipt, to make this a proper B2B payment.

Can you treat your remote service access as B2C only? Perhaps yes, but then the companies will not be able to use your service, pay from a company bank account and account this as a company cost, only individuals will be able to legally pay.

Vending machine is also located in a known physical country, so the owner knows what VAT to apply, the VAT of the country the machine is in. With software services the VAT should be applied based on the country where the buyer is located.

With payments the complexity is not only in accepting a payment, but largely in doing so legally. Someone makes a request to my company's paid service, I return 402 and get a stable coin back. Who do I invoice for this revenue? What value added tax do I apply to the invoice? If someone makes 10k paid requests within one month, do I have means of generating one invoice for them for all the usage, or is every request treated separately and results in 10k invoices? Will CloudFlare handle this for me?

You are right, but if stock repurchase does not increase market cap, dividend payment still decreases it (unless it would be fully reinvested in the same stock, which it is not, it is largely reinvested in largest caps).

Could outperformance of largest cap companies be partially explained by dividends paid by smaller caps? Reasoning behind this:

* Index investing raises in popularity, with index funds that automatically reinvest dividends being often preferred due to their tax efficiency.

* Large caps prefer to repurchase stocks, stock repurchases contribute fully towards a given company share price increase.

* Smaller caps still pay dividends, these dividends are then reinvested by index funds and the reinvestment is weighted by capitalization, so large caps share price benefits more from repurchases done with dividend cash paid by smaller caps. When dividend is paid, share price of a company that paid it is reduced, which further widens the performance gap between large and smaller caps.

I work on a Linux sandbox that makes it easy to hide sensitive files from AI agents while keeping the files they need accessible. Check it out: https://github.com/wrr/drop