Hacker News new | past | comments | ask | show | jobs | submit login

OpenBSDs pledge[0] system call is aimed at helping with this. Although, it's more of a defense-in-depth measure on the maintainers part and not the user.

> The pledge() system call forces the current process into a restricted-service operating mode. A few subsets are available, roughly described as computation, memory management, read-write operations on file descriptors, opening of files, networking (and notably separate, DNS resolution). In general, these modes were selected by studying the operation of many programs using libc and other such interfaces, and setting promises or execpromises.

[0]: https://man.openbsd.org/pledge.2




Pledge is for self-isolating, it helps with mistakes but not against intentional supply chain attacks.


How so? Obviously this is ineffective at the package level but if the thing spawning these processes, like the GitHub runners or Node itself added support to enter a "restricted" mode and pledged then that would help, no?


According to https://www.openbsd.org/papers/eurobsdcon2017-pledge.pdf pledge turns off upon execve. Surely it would be quite limiting for runners to use it.

As far as I see its purpose is mostly a mitigation/self-defence for vulnerabilities in C-based apps, so basically limiting what happens once the attacker has exploited a vulnerability. Maybe it has other uses.

It could be used defending against bugs in the Node runtime itself, as you say, but as I understand vulnerabilities in the Node runtime itself are quite rare, so more fine-grained limitations could be implemented within itself.


I'm not much of an openbsd user, but I have been meaning to understand if this is the hole execpromises is intended to fill.

At the very least, I think execpromises was added a year after the documentation that you linked, so it's worth looking into.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: