brynet (u/brynet) - Readit News

brynet commented on FreeBSD Capsicum vs. Linux Seccomp Process Sandboxing vivianvoss.net/blog/capsi... · Posted by u/vermaden

brynet · 4 days ago

EDIT: Article seems to have been updated to remove mention of Chromium.

This article contains a lot of errors, for example Chromium on FreeBSD does NOT use Capsicum, it never has. That was experimental and invasive work done 17 years ago that was NEVER committed to their official ports repository. In fact, not a single browser on FreeBSD uses Capsicum or any form of sandboxing _at all_.

https://github.com/rwatson/chromium-capsicum

https://www.freshports.org/www/chromium/

https://cgit.freebsd.org/ports/log/www/chromium/Makefile?qt=...

Contrast that with OpenBSD, where the Chromium port has used pledge(2) since January 2016, and unveil(2) since 2018. Both are enabled by default. Mozilla Firefox ports also use both pledge and unveil since 2018-2019, with refinements over the years.

https://marc.info/?l=openbsd-ports-cvs&m=145211683609002&w=2

https://marc.info/?l=openbsd-ports-cvs&m=153250162128188&w=2

OpenBSD's fork of tcpdump has been privsep for ~22 years, and its packet parser runs with no privileges. It's pledged tightly "stdio" and has no network/filesystem access, and uses OpenBSD specific innovations like bpf descriptor locking (BIOCLOCK) missing from both FreeBSD/Linux tcpdump today (despite FreeBSD adding the ioctl in 2005).

In the years since it was added, the reason Capsicum has only been applied to a handful of utilities is because it's a tree barren of decades worth of incremental work on privilege separation and security research.

brynet · 4 days ago

> EDIT: Article seems to have been updated to remove mention of Chromium.

Archive: https://archive.ph/rLmTq

brynet commented on FreeBSD Capsicum vs. Linux Seccomp Process Sandboxing vivianvoss.net/blog/capsi... · Posted by u/vermaden

limagnolia · 4 days ago

I would like to see a comparison of capsicum and pledge/unveil. Is capsicum much more difficult to use? Is it inherently less secure?

brynet · 4 days ago

It's very difficult to reason about, for instance compare the OpenSSH sshd sandbox implementations.

https://github.com/openssh/openssh-portable/blob/master/sshd...

https://github.com/openssh/openssh-portable/blob/master/sand...

w/ Capsicum, beyond faffing around with some file descriptors, it's unclear what security cap_enter() adds:

https://github.com/openssh/openssh-portable/blob/master/sand...

brynet commented on FreeBSD Capsicum vs. Linux Seccomp Process Sandboxing vivianvoss.net/blog/capsi... · Posted by u/vermaden

brynet · 4 days ago

EDIT: Article seems to have been updated to remove mention of Chromium.

This article contains a lot of errors, for example Chromium on FreeBSD does NOT use Capsicum, it never has. That was experimental and invasive work done 17 years ago that was NEVER committed to their official ports repository. In fact, not a single browser on FreeBSD uses Capsicum or any form of sandboxing _at all_.

https://github.com/rwatson/chromium-capsicum

https://www.freshports.org/www/chromium/

https://cgit.freebsd.org/ports/log/www/chromium/Makefile?qt=...

Contrast that with OpenBSD, where the Chromium port has used pledge(2) since January 2016, and unveil(2) since 2018. Both are enabled by default. Mozilla Firefox ports also use both pledge and unveil since 2018-2019, with refinements over the years.

https://marc.info/?l=openbsd-ports-cvs&m=145211683609002&w=2

https://marc.info/?l=openbsd-ports-cvs&m=153250162128188&w=2

OpenBSD's fork of tcpdump has been privsep for ~22 years, and its packet parser runs with no privileges. It's pledged tightly "stdio" and has no network/filesystem access, and uses OpenBSD specific innovations like bpf descriptor locking (BIOCLOCK) missing from both FreeBSD/Linux tcpdump today (despite FreeBSD adding the ioctl in 2005).

In the years since it was added, the reason Capsicum has only been applied to a handful of utilities is because it's a tree barren of decades worth of incremental work on privilege separation and security research.

brynet commented on Ask HN: What Are You Working On? (March 2026) · Posted by u/david927

brynet · 4 days ago

Making rent as an open source developer.

Shamelessly trying to attract new monthly sponsors and people willing to buy me the occasional pizza with my crap HTML skills.

https://brynet.ca/wallofpizza.html

brynet commented on OpenBSD on SGI: A Rollercoaster Story miod.online.fr/software/o... · Posted by u/brynet

lproven · 7 days ago

> FAIK Loongson is dead and isn't made anymore,

Wrong. It is alive and well and in production from several vendors.

https://www.loongson.cn/EN

> Loongson was a little-endian arch

True.

https://loongson.github.io/LoongArch-Documentation/LoongArch...

But... so?

> LoongArch is a new ISA

Partly. It is new but it's still close. A former colleague wrote about it:

https://www.theregister.com/2021/11/02/china_loongson_mips/

The article cites this post on the LKML:

https://lore.kernel.org/lkml/87pmu1q5ms.wl-maz@kernel.org/

« You keep saying "not MIPS", and yet all I see is a blind copy of the MIPS code. »

Alpine supports it:

https://wiki.alpinelinux.org/wiki/Loongarch64

Debian is working on it:

https://wiki.debian.org/LoongArch

Gentoo is working on it:

https://wiki.gentoo.org/wiki/Project:LoongArch

Doesn't sound dead to me. Sounds a lot more alive than multiple architectures that OpenBSD does support.

brynet · 7 days ago

I didn't say Loogson the company was dead, or that LoongArch was either. I said the predecessor Loongson/Godson CPUs are, like the 2E and 2F, which were MIPS-compatible. They're not manufactured anymore, and were practically unobtainium when they were.

LoongArch is not MIPS, despite it having similarities. It's a new platform/ISA and requires a completely different toolchain and new OS port.

It is not at all "new MIPS-family hardware is being made today" like you originally wrote, and it has little to no relevance to SGI hardware.

brynet commented on OpenBSD on SGI: A Rollercoaster Story miod.online.fr/software/o... · Posted by u/brynet

lproven · 7 days ago

As I understand it, Loongson is very close to MIPS. I think I remember reading that just 4 patented instructions were removed from the MIPS ISA, and I am not even sure that they were replaced.

If so, that means that new MIPS-family hardware is being made today. And ISTM that represents a new target market or audience for this.

brynet · 7 days ago

AFAIK Loongson is dead and isn't made anymore, and unlike OpenBSD/sgi, Loongson was a little-endian arch. OpenBSD/octeon is a closer match, but also discontinued as Cavium switched to making ARM CPUs.

LoongArch is a new ISA and isn't MIPS compatible, and OpenBSD doesn't support it.

brynet commented on OpenBSD on SGI: A Rollercoaster Story miod.online.fr/software/o... · Posted by u/brynet

fleeno · 8 days ago

I wish it was still supported, but I'm sure I was one of very few that was actually using it! Even then it was just for fun.

brynet · 8 days ago

There is someone on GitHub who's been trying to keep OpenBSD/sgi alive out-of-tree using bits and pieces (e.g: userland binaries) of OpenBSD/octeon, which remains supported.

https://github.com/the-machine-hall/openbsd-sgi