Check also https://github.com/wrr/drop which is a higher-level tool than bwrap. It allows you to make such isolated sandboxes with minimal configuration.
This looks nice but I wouldn't trust a very fresh tool to do security correctly.
As a higher-level alternative to bwrap, I sometimes use `flatpak run --filesystem=$PWD --command=bash org.freedesktop.Platform`. This is kind of an abuse of flatpaks but works just fine to make a sandbox. And unlike bwrap, it has sane defaults (no extra permissions, not even network, though it does allow xdg-desktop-portal).
Shame it's not a bit more mature, it does look like more the sort of thing I want. I use firejail a bit, but it's a bit awkward really.
To be honest - and I can't really believe I'm saying it - what I really want is something more like Android permissions. (Except more granular file permissions, which Android doesn't do at all well.) Like: start with nothing, app is requesting x access, allow it this time; oh alright fine always allow it. Central place to manage it later. Etc.
The kernel is pretty much from scratch. It provides a FreeBSD compatible syscall interface for the syscalls that BEAM calls, as well as the FreeBSD runtime loader. I do make healthy use of FreeBSD libraries to provide the OS, you can get an idea of what I pull from the file names in the Makefile [1]. Building an OS is a lot, so I tried to stick to the parts I find fun and interesting. Things like a NIC driver in Erlang [2] (with NIFs to copy to/from device memory). But process / thread creation is original, memory management is original (not necessarily good), time keeping is original, etc. I used existing code and interfaces so I didn't have to write a bootloader, memcpy, and lots of other stuff.
DragonFlyBSD would be really interesting here as well since its kernel has Light Weight Kernel Threads that use message passing. Similar in shape to Erlang/BEAM. Though I guess you've built the kernel in Erlang... so wrong abstraction.
My kernel is in C. BEAM is in userspace. Most of the drivers are in userspace too. Turns out, if you let userspace mmap whatever address it wants to, and have access to all the i/o ports, plus have a way to hook interrupts, you can write drivers in userspace.
You could run beam as init with an existing kernel, but I wanted to explore something with less kernel.
In Europe there have always been a good selection of affordable, entry-level vehicles, but recently these affordable choices have largely vanished. Toyota Corolla, the best-selling car in the world, is about 100% more expensive than pre-covid. Toyota Yaris, originally a small, city car, has gotten bigger, and more expensive. Basically, small, city car options are disappearing. Short-term, this is beneficial for car makers, because they sell more expensive options with larger margins, but it creates a large gap to fill. Chinese manufacturers make a multitude of models at very competitive prices and currently only taxes are keeping these models from dominating the markets. Long term, automakers must return to making affordable cars with smaller margins to survive.
I work on a sandboxing tool similarly based on an idea to point the user home dir to a separate location (https://github.com/wrr/drop). While I experimented with using overlayfs to isolate changes to the filesystem and it worked well as a proof-of-concept, overlayfs specification is quite restrictive regarding how it can be mounted to prevent undefined behaviors.
I wonder if and how jai managed to address these limitations of overlayfs. Basically, the same dir should not be mounted as an overlayfs upper layer by different overlayfs mounts. If you run 'jai bash' twice in different terminals, do the two instances get two different writable home dir overlays, or the same one? In the second case, is the second 'jai bash' command joining the mount namespace of the first one, or create a new one with the same shared upper dir?
'Using an upper layer path and/or a workdir path that are already used by another overlay mount is not allowed and may fail with EBUSY. Using partially overlapping paths is not allowed and may fail with EBUSY. If files are accessed from two overlayfs mounts which share or overlap the upper layer and/or workdir path, the behavior of the overlay is undefined, though it will not result in a crash or deadlock.'
If an author of a PR just generated code with an LLM, the GitHub PR becomes an incredibly inefficient interface between a repository owner and the LLM. A much better use of the owner time would be to interact with LLM directly instead of responding to LLM generated PR, waiting for updates, responding again, etc.
As a project maintainer, I don't want to interact with someone's LLM. If a person submits a PR, using LLM or not, the person is responsible for any problems with it. How they respond to review is a good indicator if they actually understand the code. And if they used a bot to submit the PR, I'd simply consider it a spam.
Yep, the indirection through the PR author is almost always inefficient and error-prone unless the author is really knowledgable about the code (many aren't).
This is also very detrimental to buyer experience. When you search for a specific new product, prices from different sellers can vary widely. Most often there is no way to tell what is the reason for the difference. Is the cheapest offer simply the best deal, or is it a refurbished product, or even a fake?
An extension from a trusted, non anonymous developer which is released as open source is a good signal that the extension can be trusted. But keep in mind that distribution channels for browser extensions, similarly to distribution channels for most other open source packages (pip, npm, rpm), do not provide any guarantee that the package you install and run is actually build verbatim from the code which is open sourced.
Actually, npm supports "provenance" and as it eliminated long lived access tokens for publishing, it encourages people to use "trusted publishing" which over time should make majority of packages be auto-provenance-vefified.
Unless the Chrome web store integrates with this, it puts the onus on users to continuously scan extension updates for hash mismatches with the public extension builds, which isn’t standardized. And even then this would be after an update is unpacked, which may not run in time to prevent initial execution. Nor does it prevent a supply chain attack on the code running in the GitHub Action for the build, especially if dependencies aren’t pinned. There’s no free lunch here.
If the RPM/deb comes from a Linux distribution then there is a good chance there is a separate maintainer and the binary package is always built from the source code by the distro.
Also if the upstream developer goes malicious there is a good chance at least one of the distro maintainers will notice and both prevent the bad source code being built for the distro & notify others.
I have investigated similar situation on Heroku. Heroku assigns a random subdomain suffix for each new app, so URLs of apps are hard to guess and look like this: test-app-28a8490db018.herokuapp.com.
I have noticed that as soon as a new Heroku app is created, without making any requests to the app that could leak the URL via a DNS lookup, the app is hit by requests from automatic vulnerability scanning tools. Heroku confirmed that this is due the new app URL being published in certificate authority logs, which are actively monitored by vulnerability scanners.
> certificate authority logs, which are actively monitored by vulnerability scanners
That sounds like a large kick-me sign taped to every new service. Reading how certificate transparency (CT) works leads me to think that there was a missed opportunity to publish hashes to the logs instead of the actual certificate data. That way a browser performing a certificate check can verify in CT, but a spammer can't monitor CT for new domains.
I think it was more of an intentional tradeoff, as one of the many goals of CT logs was to allow domain owners to discover certificates issued for their domains, or more generally for any interested party to audit the activity of a certificate authority.
What you're describing there is certificate... translucency, I guess?
Yes, "translucent database" was exactly the concept I thought of when asking the question. The concept is keep access to specific items easy but accessing the entire thing as a whole more costly.
This applies only to Heroku Fir and Cedar apps (apps that run in Heroku Private Spaces). Heroku Common Runtime apps still use shared wildcard certificate and their domains are not discoverable like this.
And then, they will pivot away from humanoid robots. To justifying the valuation they have already pivoted from electric cars company to self-driving taxis company, without delivering self-driving taxis, they are now pivoting to robots, before delivering the robots they will pivot to the next shinny thing. Maybe Pivot is the real Tesla product that justifies the crazy valuation.
In winter, even on a sunny day, only tiny fraction of your skin is exposed to sun. 10-30 min of sun when you are wearing tshirt and shorts is much different from 10-30 min of sun when you are wearing long sleeves, gloves, and a scarf.
It's not really the exposed skin that's the issue. At higher latitudes the ultraviolet (UVB) gets scattered by the longer path through the atmosphere and so even if you were naked you still wouldn't be getting enough.
reply