Hacker News Reader

Comment by gigatexal | Hacker News Reader

This is probably the single coolest feature of OpenBSD: “Also, Chromium on OpenBSD recently got unveil support. If you run it with --enable-unveil, Chromium will be prevented (at the OS level) from accessing anything other than your ~/Downloads folder.”

View on HN

FWIW: On Linux, I use firejail to do this.

But it's sweet to have natively:)

Does anyone know how this works with profiles / cache? Does this force something like incognito mode? Also does this mean you can't upload / select files outside of the Downloads folder?

I wonder if it means no webcam access as that would require access to /dev?

It does have access to .cache and .config as well

Does anybody know if FreeBSD has any form of sandboxing (e.g. seccomp) available for any of the available browsers?

FreeBSD has Capsicum, but from what I’ve heard the Chromium upstream has been reluctant to integrate the patches, so they rotted.

Which is kind of weird, given they (Google) have their own port of Capsicum to Linux. Oh well.

That's really too bad -- are there no other FBSD alternatives that are maintained?

Also -- I am going to get flamed for this -- but a GPL license would have forced Google to upstream their Capsicum changes wouldn't it -- whereas the BSD license doesn't have such a mandate.

The GPL doesn't force people to upstream their changes, although it often has that affect. The GPL only forces you to give source downstream. If your customers never share the source with anyone else (and your upstream is not one of your customers) then your upstream will never get the changes. A good example of this is the game TOME. It has downloadable content that is licensed under the GPL. You get the source code when you buy the DLC. I've never seen anyone distribute it, though (and it's highly frowned upon in the community). The author has a weird idea of the GPL, though, so I don't think he really understands that anyone is allowed to distribute that code.

But in practice people usually freely distribute GPL code, so it's impossible to stop your upstream from eventually getting it.

it would be somewhat counterproductive to introduce yet another sandboxing mechanism, just to work around a problem created by upstream - especially in case of mechanism as awesome as Capsicum :-)

Yes, the GPL license would force them to share their changes. Thing is, they wanted to upstream them anyway - AFAIK the problem is on the other (accepting) side.

Yes, i guess there is little doubt that capsicum is the superior (compared to seccomp) capabilities framework, but if it's not used outside of FreeBSD's base, (e.g. ssh, bhyve, etc.) then it is indeed a shame.

How does this compare to the sandboxing on macOS? Is this just at the file level, currently?

That's pretty cool. I wish Chromium supported this on Linux too. It seems more like a Chromium feature than an openbsd feature to me though? Linux programs installed via say flatpak have this on by default.

unveil(2) is an OpenBSD-specific feature, although you could accomplish something very similar with Linux and another sandboxing tool (or SELinux, but that might be overkill). I highly recommend you read the man page for unveil(2), it's very cool: https://man.openbsd.org/unveil

> unveil(2) is an OpenBSD-specific feature

Yes, I am aware. I thought it was pretty obvious that when I said "it's a chrome feature" I didn't mean "unveil(2)" but being able to restrict access to the filesystem. Which is possible with both linux and openbsd, of course. Alas, the downvoters seem to disagree.

I think if you run a snap package without privileges it is pretty sandboxed too.

Presumably only if AppArmor is available.

ahh i didn't know that -- thanks. I think it's enabled by default on ubuntu? or was it Fedora to run SELINUX by default?

Yes, Ubuntu has it enabled by default - so Snaps are first class citizens on Ubuntu. I think the upcoming release of Debian may also have AppArmor by default.

Reply on news.ycombinator.com