3 ms·
- HEADLINE: port pledge(2) from OpenBSD - DESCRIPTION: Debian has been a great source of innovation and leadership within the OSS world. Make the next big move
by aleden 9y ago
- HEADLINE: port pledge(2) from OpenBSD
- DESCRIPTION: Debian has been a great source of innovation and leadership within the OSS world. Make the next big move by adopting pledge(2) from OpenBSD to be the first major mandatory security feature on Linux. There is little hassle in making programs use it, and the LOC in the kernel is tiny compared to say SELinux. See [1] for more details.
[1] http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.html http://www.openbsd.org/papers/hackfest2015-pledge/mgp00001.h...
- DISTRIBUTION: Any and all!
- ROLE/AFFILIATION: CS program analysis researcher with MIT/CSAIL.
- ajdlinux 9y agoThat's really something that needs to be driven from upstream - you can't really add syscalls in distro patches.
- heftysync 9y agoThis isn't as easy as it sounds. Pledge works in OpenBSD because OpenBSD is simple and all of the necessary code lives in one tree. Pledge is supported in the vast majority of OpenBSD base programs but very few ports. If programs aren't written in a careful manner or with an eye to privsep, you end up with pledges that don't protect much since they are so broad. There are a lot of programs you can't pledge even with all options turned on because pledge has a whitelist on the kernel side for what it allows. It's not impossible for Linux, but there would have to be a lot more conditional cases in the Linux kernel to handle all of the various ways that programs would use it. The Linux ecosystem is massive and the number of alternatives for even basic daemons is large. Instead of pledge, you may end up with a syscall filter or something like FreeBSD's capsicum. Both of those are more complex because it puts all of the effort on the application developer and also gets in their way. Straight syscall filters and complex systems like capsicum are designed to allow for arbitrary programs to be protected. In doing so, it moves all of the complexity to the application developer. The advantage of pledge is that it does not attempt to be completely generic. Pledge is designed for how OpenBSD programs are written and what's in the OpenBSD tree. It may evolve over time to include some functionality for ports, but the overall design is to make a subset of well written programs easy to protect. If you try to pledge arbitrary programs, you'll find it doesn't work out unless you rewrite the program logic to be more well written. Pledge is conceptually simple, but the kernel side shows how it was tightly integrated into OpenBSD's way of doing things and has evolved to make it simpler (by relaxing some behavior or whitelisting parts) and breaking up other permissions to make it more fine grained when needed.
- aleden 9y agoThese are good points. However unlike SELinux / AppArmor, a Debian package maintainer does not need to do make sure things are set up right for pledge- programs that aren't pledge'd will run just fine (i.e. all syscalls are allowed by default, not the other way around). So even though adding pledge to the kernel does nothing by itself, can't usermode programs (the ones for which pledge makes since) slowly make themselves more secure? > It's not impossible for Linux, but there would have to be a lot more conditional cases in the Linux kernel to handle all of the various ways that programs would use it. Why would there be a lot more conditional cases in the kernel? I'm just imagining having a bitvector whitelist[] for each task_struct and then in the syscall_trace_enter functions one indexes into current->whitelist if it's __NR_pledge. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/entry/common.c?h=v4.11#n60 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...