Keep in mind that back then the way to get a CD was to buy it or build it with an unofficial script or download it from a third party. Therefore I’d assume that this might mean that many CDs were sold. It could also be based on people replying to the mail you are supposed to send how things run on your system.
I couldn’t find the original source of the claim.
I think numbers for operating systems and browsers are extremely hard to get. Many systems are behind load balancers, CDNs, firewalls, etc. or not able to be reached at all. So while I agree that netcraft is a good bet compared to others it’s something to keep in mind. I myself have worked at quite a few companies running FreeBSD (and even OpenBSD when the base system was a perfect fit), but I think there was only one instance where netcraft had the opportunity to see FreeBSD until it went behind Cloudflare.
And then it even gets complicated in terms of hosts. Scaling up many tiny machines connected to the internet is really easy and as default for cloudproviders that’s frequently something like Ubuntu. In my experience BSD tends to more frequently run on physical hardware. There’s more monoliths she vertical rather than horizontal scaling.
So user to host conversion isn’t easy. On top of that there’s probably a higher chance to run FreeBSD or OpenBSD in addition to Linux than the reverse.
I always compare that with browsers. Most statistics are somehow based on JavaScript based tracking which has a much higher chance to be blocked by Linux and Firefox users than Windows and Chrome users.
So tracking is extremely hard and the more users switch to a piece of software for privacy reasons the less visible it will be. I think this is also true for OpenBSD.
This is the most common way of installation now, so it is probably the most accurate way of gauging number of users/installs. Though I have no idea what kind of stats are collected on that server.
Sure, but that doesn’t count any mirrors of bigger ones, with other non-internet installs and certainly doesn’t count anything like the vultr, digital ocean or the OpenBSD Amsterdam installs.
Also, I don’t know from the top of my head whether the master server or some CDN is used per default.
OpenBSD installs a sendmail server as part of the default install so you can email Theo and what not. So I wouldn’t be surprised if that gave the project some visibility into how many OpenBSD users exist. It’s hard to be an open source dev when you have absolutely no idea how much impact your work is having. So I wouldn’t blame them.
That’s what I meant with those emails, but I wouldn’t be surprised if only a really tiny fraction even of very committed OpenBSD users does that. And then it can be hard to know whether ten one or even less percent actually do that.
Sure you can do educated guesses but I have seen nothing so far where I think that they are certainly correct about the magnitude.
Fascinating to see what it takes to create similar paradigms in the Linux seccomp bpf world.
I’m not a fan of the command-line implementation. Folks have created those for OpenBSD occasionally and they all violate the design of pledge(2). From the man page:
Use of pledge() in an application will require at least some study and understanding of the interfaces called.
One isn’t studying and understand the application when using the “wrapper” approach. The responsibility should be on the developer of the program, not the user, to limit its syscall usage to just what is needed.
Isn’t that a bit more nuanced depending on the use case? I’d agree that it doesn’t give you the full power of pledge() and an integration in the app is preferable, but for the limited case of strictly sandboxing an “unknown” application it is still useful.
Pledge is designed to abort a program immediately when a violation occurs. By design there’s no “complain” mode like with AppArmor (and other systems attempting to secure programs externally) to “log” and “discover” what syscalls are “needed.”
Why? If you look at a lot of OpenBSD userland that uses pledge, especially those that start with elevated permissions as root, they may need to perform some syscalls during startup and then remove the ability to perform them again. Blindly prohibiting a syscall will break the privilege dropping already built into the program by the developer.
It’s not always a one-dimensional thing of “deny this syscall”. It’s “deny this syscall after we no longer need it.” Timing is everything.
Also, how is a user supposed to differentiate between an abort because of malice vs. they picked a random pledge via the cli wrapper that broke part of the program?
The cli approach, to me, is a false sense of security combined with a horrible user experience.
I don’t see where the false sense of security comes from. The pledge CLI will reduce the permissions correctly, it just might also cause the program to crash.
Sure, the CLI is a blunt tool compared to using pledge() within a program, but sometimes that’s all you need.
With the CLI wrapper, if a process ever needs a capability, then it can only allow it at the start and for the entire execution of the process. So if you only want the startup phase of a program to be able to have capability X, well, tough, capability X is allowed for the rest of the runtime of the program.
With an API, one can strategically discard capabilities over time as they are no longer required.
I think we can all agree the API is better, for exactly why you said. That doesn’t mean a wrapper is useless, it’s definitely less than ideal, but that doesn’t make it useless. or as @cmcaine put it, it’s a blunt tool. One could say the same thing about pledge in API form, it’s not as detailed as say pledge and unveil together or capsicum.
Sometimes a blunt tool is adequate for your needs, especially if it’s all you have laying around.
I’ve used such a wrapper under OpenBSD a while back, while testing a buggy program that I wrote ages ago. I just wanted to make sure it couldn’t mess with my $HOME (or any other files and directories for that matter). If it had crashed, I wouldn’t have cared if it was because of a bug or if the wrapper had broken it. You’re right to caution against using wrappers like these as security sandboxes but there are plenty of valid use cases for them.
I think a lot of folks in this discussion are conflating things like prohibiting specific directory/file access with syscall access. You example of “messing with $HOME” doesn’t need pledge so much as pledge+unveil, assuming you can’t run the program as a different user without permissions to read your personal $HOME.
This wrapper in quesiton is positioned as a “sandboxing” tool:
You example of “messing with $HOME” doesn’t need pledge so much as pledge+unveil, assuming you can’t run the program as a different user without permissions to read your personal $HOME.
Or runpledge -dpath -cpath -fpath ./this-ancient-tool (or whatever), which did not require the addition of new users, nor any source-level changes in a program I knew quite well but I had zero intention of either fixing or improving, since all I needed it to do was to send four stupid network packets so that I could look at the header. It worked fine and I really don’t care if the Special Unix Philosophical Committee approved. No, I don’t recommend doing it “in production” but I am also quite certain that the angry spectre of the Patriarch Ritchie will not come to haunt me for committing such an abhorrent sin against his teachings. I’m pretty sure he understands the concept of a dirty hack. I’m not going to architect my security solution around this.
This is certainly not how pledge() was intended to be used, sure, but that’s the mark of a powerful technology. The history of computing is littered with technologies that were used exactly the way they were intended because they weren’t really good for anything else. Unix is one big hairball of things that weren’t used the way they were originally intended. That’s why we keep using it.
I think that article does a pretty good job at explaining how this solution works (including, for that matter, how to figure out why the program crashed) which ought to be enough to understand the limits of the CLI wrapper. I don’t think there’s any danger of Aunt Tillie running into this blogpost and setting her workstation on fire by pledge.com-ing what was supposed to be a cute cat video but turned out to be a craftily-assembled virus, specifically targeting an unofficial wrapper around an unofficial port of an OpenBSD API. The CLI wrapper is certainly a less flexible approach, which the author also acknowledges. Honestly, the only negative emotion this summons within my soul is jealousy that I never sat down to do it myself in the first place.
Yes, as I said, the cases where a CLI wrapper is enough are limited. I don’t see why that means a tool for such cases shouldn’t exist, especially if we leave the world of the one-source OpenBSD userland where “every app implements this already properly and is fully trusted” is a reasonable expectation.
Given the choice of “I can easily ensure the program doesn’t do X and if it does have to make further decisions” and “I can’t ensure the program doesn’t do X” I don’t agree the second is superior.
“I can easily ensure the program doesn’t do X and if it does have to make further decisions”
How do you differentiate between a security issue vs. a bug vs. normal operating errors like lacking a file permission? This particular pledge implementation doesn’t currently work like OpenBSD’s: instead of unconditionally aborting the program it just makes the syscall return EPERM. That return value is now ambiguous.
Here’s where we get to my claim of “false sense of security.” These wrappers lead people to think they can be safe running random programs without first dropping to a lower-privilege environment because “I’m sandboxing it, so it’s ok.” If you can’t differentiate expected vs. unexpected behavior of the program, how can you determine that the sandboxing approach is working?
seccomp-bpf is very flexible, but places a huge burden on programmers. I’ve implemented the same sandboxing model with Capsicum and seccomp-bpf. The Capsicum version is <150LoC. The seccomp-bpf version is >400LoC, depends on a shared library, and requires some IPC traffic to a privileged process for things that can be done securely with Capsicum and provides less fine-grained control.
Thanks for sharing. I’m glad someone is doing this and I think it’s worthwhile.
The command line wrapper is an interesting idea, but I think it’s going to be of limited utility (without compromising security).
Often a program needs to do some “privileged things”, but only during its startup phase. Perhaps it has to open a log file startup, but then never opens more files. When using pledge() as an API, you would typically call pledge(2) to revoke the ability to open files immediately after you’ve done opening that log file. The kernel would then crash the process at runtime if it tried to open any more files after that point.
Presumably the wrapper utility can only enforce privileges upon spawning a process, so if the startup code requires opening files, then the process will be eternally allowed to open files(?). Either that, or you have some way of saying when to apply pledge restrictions.
That said, the wrapper is certainly better than nothing.
Our focus has been making Cosmopolitan Libc as awesome as possible. Implementing pledge() is one of the ways we’ve done that. The code is plain unfancy mostly standard C under an ISC license. So folks using other libc’s are more than welcome to copy what we did, so long as the copyright notice is preserved. Helping competing libraries obviously isn’t something we’re actively going out of our way to do ourselves, but we’d very much love to see a broader audience of users benefiting from our work!
I think pledge(), although convenient, is not a very good design as a syscall. Linux’s seccomp is more general and flexible, a good example of separating mechanism from policy. And with good tooling it isn’t difficult too use. The author even implemented pledge() using seccomp.
This is why there are many more pledge()’d programs in OpenBSD than seccomp applications in Linux. Because one is easier and safer to use than the other.
The linked post was from 2002. I wonder what the current figure is.
7k daily desktop users might be an overestimation tbh.
If we’re counting, network related equipment and special purpose installations, I would assume the numbers are orders of magnitudes higher.
I won’t believe any figures on BSD usage until Netcraft confirms it.
Keep in mind that back then the way to get a CD was to buy it or build it with an unofficial script or download it from a third party. Therefore I’d assume that this might mean that many CDs were sold. It could also be based on people replying to the mail you are supposed to send how things run on your system.
I couldn’t find the original source of the claim.
I think numbers for operating systems and browsers are extremely hard to get. Many systems are behind load balancers, CDNs, firewalls, etc. or not able to be reached at all. So while I agree that netcraft is a good bet compared to others it’s something to keep in mind. I myself have worked at quite a few companies running FreeBSD (and even OpenBSD when the base system was a perfect fit), but I think there was only one instance where netcraft had the opportunity to see FreeBSD until it went behind Cloudflare.
And then it even gets complicated in terms of hosts. Scaling up many tiny machines connected to the internet is really easy and as default for cloudproviders that’s frequently something like Ubuntu. In my experience BSD tends to more frequently run on physical hardware. There’s more monoliths she vertical rather than horizontal scaling.
So user to host conversion isn’t easy. On top of that there’s probably a higher chance to run FreeBSD or OpenBSD in addition to Linux than the reverse.
I always compare that with browsers. Most statistics are somehow based on JavaScript based tracking which has a much higher chance to be blocked by Linux and Firefox users than Windows and Chrome users.
So tracking is extremely hard and the more users switch to a piece of software for privacy reasons the less visible it will be. I think this is also true for OpenBSD.
The installer reaches out to a central OpenBSD server when doing an HTTP/FTP install:
https://github.com/openbsd/src/blob/master/distrib/miniroot/install.sub#L3162
This is the most common way of installation now, so it is probably the most accurate way of gauging number of users/installs. Though I have no idea what kind of stats are collected on that server.
Sure, but that doesn’t count any mirrors of bigger ones, with other non-internet installs and certainly doesn’t count anything like the vultr, digital ocean or the OpenBSD Amsterdam installs.
Also, I don’t know from the top of my head whether the master server or some CDN is used per default.
So eben here it’s kind of tricky.
OpenBSD installs a sendmail server as part of the default install so you can email Theo and what not. So I wouldn’t be surprised if that gave the project some visibility into how many OpenBSD users exist. It’s hard to be an open source dev when you have absolutely no idea how much impact your work is having. So I wouldn’t blame them.
That’s what I meant with those emails, but I wouldn’t be surprised if only a really tiny fraction even of very committed OpenBSD users does that. And then it can be hard to know whether ten one or even less percent actually do that.
Sure you can do educated guesses but I have seen nothing so far where I think that they are certainly correct about the magnitude.
I was pretty sure that post was a joke
Fascinating to see what it takes to create similar paradigms in the Linux seccomp bpf world.
I’m not a fan of the command-line implementation. Folks have created those for OpenBSD occasionally and they all violate the design of
pledge(2). From the man page:One isn’t studying and understand the application when using the “wrapper” approach. The responsibility should be on the developer of the program, not the user, to limit its syscall usage to just what is needed.
Isn’t that a bit more nuanced depending on the use case? I’d agree that it doesn’t give you the full power of pledge() and an integration in the app is preferable, but for the limited case of strictly sandboxing an “unknown” application it is still useful.
Pledge is designed to abort a program immediately when a violation occurs. By design there’s no “complain” mode like with AppArmor (and other systems attempting to secure programs externally) to “log” and “discover” what syscalls are “needed.”
Why? If you look at a lot of OpenBSD userland that uses pledge, especially those that start with elevated permissions as root, they may need to perform some syscalls during startup and then remove the ability to perform them again. Blindly prohibiting a syscall will break the privilege dropping already built into the program by the developer.
It’s not always a one-dimensional thing of “deny this syscall”. It’s “deny this syscall after we no longer need it.” Timing is everything.
Also, how is a user supposed to differentiate between an abort because of malice vs. they picked a random pledge via the cli wrapper that broke part of the program?
The cli approach, to me, is a false sense of security combined with a horrible user experience.
I don’t see where the false sense of security comes from. The pledge CLI will reduce the permissions correctly, it just might also cause the program to crash.
Sure, the CLI is a blunt tool compared to using pledge() within a program, but sometimes that’s all you need.
With the CLI wrapper, if a process ever needs a capability, then it can only allow it at the start and for the entire execution of the process. So if you only want the startup phase of a program to be able to have capability X, well, tough, capability X is allowed for the rest of the runtime of the program.
With an API, one can strategically discard capabilities over time as they are no longer required.
I think we can all agree the API is better, for exactly why you said. That doesn’t mean a wrapper is useless, it’s definitely less than ideal, but that doesn’t make it useless. or as @cmcaine put it, it’s a blunt tool. One could say the same thing about pledge in API form, it’s not as detailed as say pledge and unveil together or capsicum.
Sometimes a blunt tool is adequate for your needs, especially if it’s all you have laying around.
I don’t disagree.
I’ve used such a wrapper under OpenBSD a while back, while testing a buggy program that I wrote ages ago. I just wanted to make sure it couldn’t mess with my
$HOME(or any other files and directories for that matter). If it had crashed, I wouldn’t have cared if it was because of a bug or if the wrapper had broken it. You’re right to caution against using wrappers like these as security sandboxes but there are plenty of valid use cases for them.Such as?
I think a lot of folks in this discussion are conflating things like prohibiting specific directory/file access with syscall access. You example of “messing with $HOME” doesn’t need pledge so much as pledge+unveil, assuming you can’t run the program as a different user without permissions to read your personal $HOME.
This wrapper in quesiton is positioned as a “sandboxing” tool:
https://github.com/jart/cosmopolitan/blob/0a589add4167c1b5873eddd2904569e90bf4f27c/tool/build/pledge.c#L86
That’s what I’m taking issue with from a “false sense of security” standpoint in my claim.
Or
runpledge -dpath -cpath -fpath ./this-ancient-tool(or whatever), which did not require the addition of new users, nor any source-level changes in a program I knew quite well but I had zero intention of either fixing or improving, since all I needed it to do was to send four stupid network packets so that I could look at the header. It worked fine and I really don’t care if the Special Unix Philosophical Committee approved. No, I don’t recommend doing it “in production” but I am also quite certain that the angry spectre of the Patriarch Ritchie will not come to haunt me for committing such an abhorrent sin against his teachings. I’m pretty sure he understands the concept of a dirty hack. I’m not going to architect my security solution around this.This is certainly not how
pledge()was intended to be used, sure, but that’s the mark of a powerful technology. The history of computing is littered with technologies that were used exactly the way they were intended because they weren’t really good for anything else. Unix is one big hairball of things that weren’t used the way they were originally intended. That’s why we keep using it.I think that article does a pretty good job at explaining how this solution works (including, for that matter, how to figure out why the program crashed) which ought to be enough to understand the limits of the CLI wrapper. I don’t think there’s any danger of Aunt Tillie running into this blogpost and setting her workstation on fire by
pledge.com-ing what was supposed to be a cute cat video but turned out to be a craftily-assembled virus, specifically targeting an unofficial wrapper around an unofficial port of an OpenBSD API. The CLI wrapper is certainly a less flexible approach, which the author also acknowledges. Honestly, the only negative emotion this summons within my soul is jealousy that I never sat down to do it myself in the first place.Yes, as I said, the cases where a CLI wrapper is enough are limited. I don’t see why that means a tool for such cases shouldn’t exist, especially if we leave the world of the one-source OpenBSD userland where “every app implements this already properly and is fully trusted” is a reasonable expectation.
Given the choice of “I can easily ensure the program doesn’t do X and if it does have to make further decisions” and “I can’t ensure the program doesn’t do X” I don’t agree the second is superior.
How do you differentiate between a security issue vs. a bug vs. normal operating errors like lacking a file permission? This particular pledge implementation doesn’t currently work like OpenBSD’s: instead of unconditionally aborting the program it just makes the syscall return
EPERM. That return value is now ambiguous.Here’s where we get to my claim of “false sense of security.” These wrappers lead people to think they can be safe running random programs without first dropping to a lower-privilege environment because “I’m sandboxing it, so it’s ok.” If you can’t differentiate expected vs. unexpected behavior of the program, how can you determine that the sandboxing approach is working?
seccomp-bpf is very flexible, but places a huge burden on programmers. I’ve implemented the same sandboxing model with Capsicum and seccomp-bpf. The Capsicum version is <150LoC. The seccomp-bpf version is >400LoC, depends on a shared library, and requires some IPC traffic to a privileged process for things that can be done securely with Capsicum and provides less fine-grained control.
This is literally what the blog author did: they implemented pledge() using seccomp.
Uh yeah. What I’m saying is it’s interesting seeing how to adapt seccomp bpf to recreate pledge. What do you think I’m implying?
Thanks for sharing. I’m glad someone is doing this and I think it’s worthwhile.
The command line wrapper is an interesting idea, but I think it’s going to be of limited utility (without compromising security).
Often a program needs to do some “privileged things”, but only during its startup phase. Perhaps it has to open a log file startup, but then never opens more files. When using
pledge()as an API, you would typically callpledge(2)to revoke the ability to open files immediately after you’ve done opening that log file. The kernel would then crash the process at runtime if it tried to open any more files after that point.Presumably the wrapper utility can only enforce privileges upon spawning a process, so if the startup code requires opening files, then the process will be eternally allowed to open files(?). Either that, or you have some way of saying when to apply pledge restrictions.
That said, the wrapper is certainly better than nothing.
Sorry, I should have read all of the comments first. As voutilad said:
It’s a pity this requires Cosmopolitan. I’d like to be able to use this directly from other languages without having to pull in another 110k loc of C.
Oh well, the code doesn’t look too obtuse. Shouldn’t be too much of a hassle to port.
Our focus has been making Cosmopolitan Libc as awesome as possible. Implementing pledge() is one of the ways we’ve done that. The code is plain unfancy mostly standard C under an ISC license. So folks using other libc’s are more than welcome to copy what we did, so long as the copyright notice is preserved. Helping competing libraries obviously isn’t something we’re actively going out of our way to do ourselves, but we’d very much love to see a broader audience of users benefiting from our work!
I think pledge(), although convenient, is not a very good design as a syscall. Linux’s seccomp is more general and flexible, a good example of separating mechanism from policy. And with good tooling it isn’t difficult too use. The author even implemented pledge() using seccomp.
This is why there are many more pledge()’d programs in OpenBSD than seccomp applications in Linux. Because one is easier and safer to use than the other.
When I see this, I can only think back not that long ago when Linus T. called the BSD community a bunch of masturbating monkeys.