Applying Sandbox Security to Node.JS Unikernels with OpenBSD Pledge and Unveil

https://nanovms.com/dev/tutorials/applying-sandbox-security-node-js-unikernels-openbsd-pledge-unveil

Making openat(2) and friends more useful in practice

Contributed by Peter N. M. Hansteen on 2025-05-28 from the best laid plans of pufferfish and ... dept. Reining in file system access is hard to get right, even for OpenBSD developers.

In a message to tech@ titled openat(2) is mostly useless, sadly Theo de Raadt (deraadt@) describes how the openat(2) family of system calls has failed to live up to expectations in practice, and he proposes changes that may improve the situation.

https://undeadly.org/cgi?action=article;sid=20250529080623

Для Яндекс Облака есть идея с поддержкой OpenBSD в качестве гостевой ОС. Проголосуем?

https://yandex.cloud/ru/features/1360

#openbsd

Theo de Raadt has completed an overhaul of the gprof process profiling facility on #OpenBSD -current, the existing profil(2) system call is deprecated, with a new enhanced profil(2) interface replacing it to better work with privsep programs with current mitigations.

It is no longer possible to startup profiling manually with monstartup(3), it's now only possible via the -pg compiler flag.

deraadt@ modified src/lib/csu/crt0.c: As a first step in making the gprof profiling subsystem compatible with all of our privsep work, add an ELF note to gcrt0, this means we know which binaries have been compiled with -pg.
ok kettenis

deraadt@ modified src/*: In the old gprof profiling subsystem, the simplistic profil() syscall told the kernel about the sample buffer, and then the normal exit-time
_mcleanup() would finalize the buffer, open()'ed a file and write out the details. This file opening has become increasingly impossible because of our privsep / privdrop, chroot, setresuid uid-dropping, pledge, unveil, and other efforts. So people stopped using gprof.
Programs which needed profiling needed substantial mitigation removal changes to put them under test.

In the new gprof profiling subsystem, profil() is enhanced to provide more buffer information to the kernel, as well as better instructions for where the file should be written. At normal exit-time mcleanup(), after finalizing the buffer, the process simply terminates via _exit(2), and the kernel does all the opening and writing in a safe way. The file is now deposited into the starting directory, or into PROFDIR as determined at program start, with safety issues taken into consideration.

Additional side effects:

• The monstartup(3) interface will go away, it cannot be supported.
• profil() is now allowed in pledge "stdio", access is decided by the -pg ELF note
• gmon.out is renamed to gmon.progname.pid.out, due to pervasive multi-processprivsep practices

prompted originally by job and claudio for use in rpki-client and bgpd
advice from kettenis and claudio

@bsdcan 2025 Info:

Tutorials: June 11-12, 2025
Conference: June 13-14, 2025
full list of talks here:

https://indico.bsdcan.org/event/5/contributions/#

North Americas biggest *BSD Event.
3 rooms, 2 days, Zero filler. Plus we have tutorials, Shawarma, and a fun auction at the end.

#bsdcan

Status report on optional Rust in FreeBSD support

https://lwn.net/Articles/1022040/ #LWN

OpenSMTPD 7.7.0p0 released

https://www.opensmtpd.org/announces/release-7.6.0p0.txt

#release

There's new Intel CPU microcode/ucode available today...

Just a reminder that updated #OpenBSD firmware packages are ready to install for both -current snapshots as well as 7.7 via fw_update(8).

:flan_peek:​

jsg@ modified sysutils/firmware/intel/*: update intel microcode to 20250512

release notes: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20250512

If you haven't ran fw_update recently it's a good idea in general. AMD CPUs will also receive updates, but they're slightly less dramatic.

Time to update microcode on your Intel processors (gen >9)...

New speculative prediction bug lets you capture /etc/shadow with 99% reliability. They didn't make anything like it work on AMD or ARM... yet...

https://comsec.ethz.ch/research/microarch/branch-privilege-injection/

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01247.html

https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20250512

I'm looking for a more powerful successor of the APU2. Does anyone have a recommendation? Anyone maybe experience with the devices from Protectli, the Vault Pro VP2430 with Intel I226-V igc(4) perhaps?

It has to run #OpenBSD and a dozen of 100mbit #WireGuard tunnels.

/cc @mischa

An interesting one perhaps for those already deep in the network trenches. :flan_smile:​

David Gwynne (dlg@) has added erspan(4), a new network pseudo-device driver, for the ERSPAN (Encapsulated Remote Switch Port Analyzer) Type II protocol, as found on many Cisco switches.

dlg@ src/sys/net/if_gre.c: add support for the ERSPAN Type II protocol

ERSPAN is a specific GRE 0 protocol id with GRE [Generic Routing Encapsulation] sequence numbers enabled, with it's own shim header, and then an Ethernet payload.

it is intended for use as a network based packet capture format, but it's implemented as an Ethernet tunnel interface here. as an interface, it reuses all the BPF based infrastructure and tooling available to us. it's able to send packets too, which allows it to be added as a span port to bridge/veb setups.

the driver can also act as a collector for any ERSPAN Type II packets sent to it. it's also set up with an extra BPF DLT_LOOP interface that includes the encapsulation headers so you can tell where the encapsulated packets came from.

ok claudio@ sthen@

Context: https://marc.info/?l=openbsd-tech&m=174701304626457&w=2

#OpenBSD

"Domina rcctl en OpenBSD" por The OpenBSD guy
https://youtu.be/GGsxdfxDOkM

The state of SSL stacks:

https://www.haproxy.com/blog/state-of-ssl-stacks

Good news for anyone running heavily threaded programs (using futexes) on #OpenBSD.

David Gwynne (dlg@) has followed up on previous work on __thrsleep/ __thrwakeup, mostly improving Go programs, to now also avoid lock contention in futex(2) calls as well.

Zoom zoom. :flan_racer:​ 🏎️​

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

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

The end of an era, Usenix announces this July will be its final annual conference. https://www.usenix.org/blog/usenix-atc-announcement

This is a gruelling summary of all the things wrong with OpenSSL https://www.haproxy.com/blog/state-of-ssl-stacks I've mostly watched this whole thing from the sidelines, but was also affected noting that private key parsing suddenly became 70 times slower. I think they've now improved it to "only" be 10-20 times slower, and there does not seem any effort to work on it any more.

Anyone success in implementing NAT64 on #openbsd where the egress interface lives in another rdomain then the incoming interface. Path out works just fine (af-to + rtable in pf work as expected) and I see ipv4 packets going out and replys coming back. There is also a pf state created but unlinke "normal v6 traffic" where returning packages are put back into the correct rdomain this does not seem to work for af-to + trable created pf states.

Run FreeBSD, OpenBSD & NetBSD VMs in Incus

https://gyptazy.com/run-freebsd-openbsd-netbsd-vms-in-incus/

We are now down to 9080 sparc64 packages for 7.7. The slow death continues. 135 years until we hit zero.

@jadi This "#OpenBSD is secure!" claim always annoyed me a lot, mainly because it doesn't tell anything: #Security in IT can only ever be defined in a context of #threat models. Without that, it's meaningless. Somewhat recently, I discovered this:

https://isopenbsdsecu.re/

I should warn it uses some sarcasm and other confrontative language in some parts, unfortunately. But it seems to be a pretty professional analysis and assessment of (mostly) the "mitigations" OpenBSD provides in an attempt to counter "typical" attacks by at least making them harder.

I should also add that I consider this a very interesting and helpful read, and still consider OpenBSD a great project that came up with lots of great stuff (I recently used their #bcrypt code after doing some research on password hashing, for example). And I don't agree with every single criticism on that page either. I just think it's important to build assessments whether something "is secure" on a serious analytical foundation.