> allows resource requests or denies them and (hopefully) kills the application

Why is killing the application desirable behaviour over just denying the request?

There's a school of thought in security that believes you should hard fail at any attempt to violate an invariant. I believe the linux grsec patches do this. They will just crash the kernel if they see something at runtime that they don't like.

Since the author is using cgi:

However, this is definitely something in the crosshairs of ksql(3): forking a process, like kcgi(3) does, that handles the database I/O and communicates with the master over pipes.

If they do this, then they can just use seccomp SECCOMP_SET_MODE_STRICT, which is the first thing described in the seccomp man page and in the Wikipedia page. And is also the original/first mode of seccomp to be available.

I believe capsicum would likewise be trivial to use: You can just immediately lock things down completely. (Perhaps just cap_enter() is sufficient?)

SECCOMP_SET_MODE_STRICT is pretty hard to use - you cannot allocate memory for example.

pledge(2) is great. However, BCHS sucks.

No. Do not write your webapp in C. I'm serious here. Write it in Python, write it in TCL, write it in Lisp. But write it an environment that is at least semi-manged.

FFIs are pretty good. You can call pledge from your app. But don't write your app in C. If you're doing anything serious, it's a bad idea.

Well... there is at least some sense in writing a webapp in C. If you rely on operating system primitives for security (processes, Unix filesystem permissions, seccomp/pledge/capsicum) instead of language features (bounds checking, garbage collection, etc.) then just maybe you could get performance gains while still being secure.

But in reality writing applications in a hosted environment/virtual machine is more performant than writing it in C and locking it down with operating system features. And of course more secure.

The author's efforts would be better spent on improving the performance of OS-based security (processes, filesystems), than attempting to use that security as it stands. There are all kinds of tricks that could be implemented to improve things...

If you are using CGI, then you probably already don't care about performance.

On top of that, the CPU throughput overhead of using a compiled managed language is typically less than a factor of 2, which, combined with the fact that the majority of web applications are not compute bound means the number of webapps that it would make any sense to write in C is nearly zero.

Pretty much all pithy advice (such as "Don't write your webapps in C") has an implicit exception "Unless you fully understand why I made this recommendation and have good reasons for why they don't apply."

That exception is not made explicit because 1) It would make the advice less pithy and 2) Then those who would most benefit from the advice convince themselves that it doesn't apply to them.

"If you are using CGI, then you probably already don't care about performance."

So...I think you're missing a few pieces of the puzzle with this statement. The statement is a truism that is right almost always, but it has exceptions, and this is one of those exceptions.

CGI is slow when startup time for your app is slow, because of a VM, because of the library loading overhead, because of environment setup, because of some thing that isn't really the fault of CGI per se. CGI can be fast, or at least fast enough, if startup time for your app is very fast. An app written in C, statically linked, could potentially start and respond faster than many dynamic language apps could even when running in an app server. C is fast. C is small. C is also particularly error-prone, would be a little verbose for web apps, and does not have a good ecosystem of support libraries for web apps, but even if running it without an app server in a CGI mode it could be fast enough for most deployments.

The CGI interface is not why CGI apps are slow. CGI apps are slow because startup of many modern language environments is slow. C is a language that doesn't have to be slow in that context. (Though, it could be faster still by using an FCGI or other app server model and having your C web app running all the time, so it just has to answer requests over a socket or whatever...though async programming in C is also hard to get right for inexperienced programmers.)

Huh. I wonder what the start time is on the language I'm using for CGI work. (I'm using CHICKEN, which is a compiled Scheme R5RS implementation with numerous extensions).

Probably fine for some things, since it is compiled, and, as I understand it is pretty fast. I don't know a lot about the internals of chicken, but since it's a Scheme wouldn't it need some kind of VM for macros and memory management and such? That'd impose some kind of startup overhead that C wouldn't have. But, then again, Perl can start fast enough for some things (though most Perl web app developers use some sort of app server, because they rely on a bunch of libraries that would increase startup time remarkably if it had to happen for every request).

Do you write command line apps with CHICKEN? Are they super fast to start, like instant (comparable to something written in C or small Perl scripts)? If so, then CGI could probably be fast enough for some use cases. If you can perceive the startup time, then no, it'd be kinda sucky when used with CGI.

If you're considering writing it in C, you probably have some reason why you don't want to use a scripting language. To that end, I'd suggest using something like Rust instead of C.

Maybe I'm writing it in C because I like the language, enjoy using it and am good with it? And I know it works everywhere I want it, even years later? I hate to be told what I should or shouldn't use.

And your users will certainly enjoy all the security issues your code will have.

Someone with say 10-20 years of experience in a language will write a more secure program then someone just started in any language ... And even if you program in a "safe" language, you still make bugs, and all those bugs passed the compiler/parser, so your language obviously didn't help you there. There are a lot of code written in C in the wild, witch means there are also a lot of bad code.

There are business logic bugs, and there are memory corruption bugs. One of those leads to RCEs a lot more often than the other. One of those is a lot easier for the compiler to prevent than the other.

Yes, but there are ways to prevent most memory corruption bugs, even, if you're using an OS with a non-terrible malloc implementation. The gnu malloc that most people know is a terrible antiquity that should have been replaced decades ago -- mallocs like OpenBSD's make a lot of memory corruption bugs a lot harder to exploit.

Someone who capably sets out to write their web application back-end in C most likely is aware of any security issues. If they exist in the finished product, their presence is going to be due to laziness, not ignorance.

Given the fact that virtually every significant piece of C software has some sort of vulnerability in it, this comment is demonstrably false.

virtually every significant piece of C software has some sort of vulnerability in it

The GNU 'echo' program is pretty significant, in the sense it's installed widely, and used widely. What sort of vulnerability exists?

Then you shouldn't like BCHS or pledge because the author likewise tells you that you should use it and not other things. Regardless of that, this page is all about making the web apps secure. The BCHS page talks something similar. Then, within all this, they recommend a language that goes out of its way to make apps insecure when alternatives exist that don't. Big communities behind some these days.

Recommending against C for web apps is wise in this context.

Then you shouldn't like BCHS or pledge because the author likewise tells you that you should use it and not other things.

What a non sequitur. That I do not like being told what to (not) use has no bearing whatsoever on whether I can like or dislike the thing that someone somewhere is advocating for or against.

That was partly my point. You bring up you don't like being told what you should or shouldn't use. Yet, you use a product doing exactly that of your own free will. You probably started to after someone shared a link to affect your decision-making. So, a pointless counter in reply to up-thread recommendations.

Do we speak a different language? Because again I just do not understand how any of what you're saying follows.

Yes, I use C. Is the programming language telling me to use this or that? No, I am telling it to do this or that.

And no, I am not using it because somebody told me to. I am using it because (as I said above), I like it, I enjoy using it, I am good with it, and feel like it's a good fit for the values I hold. Opinions shared by other people may have affected my perception, but I am not using the language because somebody tells me to.

Ok. Let's assume all that in light of your previous reply. Do you like your web apps to be secure? Or do you value the personal fulfillment of using C over that? A choice between those two is likely at the bottom of this. "Avoid C if security is priority" still stands with you making a different choice for different priorities.

The author dismisses capsicum without much thought. Really, any application you've already restructured to be sandboxed under pledge(2) is trivial to capsicumize.

Do you know of any good guides for doing that? I tried capsicum at some point but got lost.

You may learn a lot from FreeBSD reviews about sandboxing, like these:

https://reviews.freebsd.org/D8543

https://reviews.freebsd.org/D8290

That is probably the reason for the quick uptake of pledge in OpenBSD's tree. A lot of their software had already been restructured or rewritten for privilege separation. But looking at a few capsicum diffs in the FreeBSD codebase I'm not sure I'd call those trivial. You can do more with capscium so there is more code to deal with those abilities. But even simple cases hit 20+ lines of code with multiple failure states to deal with. Compared to the usual two line pledge diffs that's quite a bit more work to do.

Compared to the usual two line pledge diffs that's quite a bit more work to do.

I don't think you're comparing apples and oranges. OpenBSD has just already done the restructuring as a separate commit; in FreeBSD you see it all at the same time, so it looks bigger. Capsicum for simple stuff is only a few lines, especially with the "helper" subroutines.

In some cases we can get more functionality with the same restriction, or more restriction than OpenBSD due to more specific constraints. So there's more code, but it also does more. It can be a trade-off.

That statement was comparing capsicum being applied to programs that were also pledged in around 2 lines of code. A few of the programs on the wiki as examples of capsicum applications originated from OpenBSD so they were primed and ready to go. Even those best cases are much more involved than pledge.

To use the example of the unix tr utility, the change to use pledge required the standard two line diff.

  if (pledge("stdio", NULL) == -1)
		  err(1, "pledge");

tr.c was the one of the earliest programs pledged (back when it was called tame). The original diff was a one liner before they start doing the "pledge or error out".

http://marc.info/?l=openbsd-tech&m=144070638327053

  +	tame(TAME_STDIO, NULL);

The capsicum diff required the following

https://reviews.freebsd.org/D7928 https://reviews.freebsd.org/file/data/4exxbzvuc3dayrvdj6qe/P...

  +	cap_rights_t rights;
  +	unsigned long cmd;

(...)

  +	cap_rights_init(&rights, CAP_FSTAT, CAP_IOCTL, CAP_READ);
  +	if (cap_rights_limit(STDIN_FILENO, &rights) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit rights for stdin");
  +	cap_rights_init(&rights, CAP_FSTAT, CAP_IOCTL, CAP_WRITE);
  +	if (cap_rights_limit(STDOUT_FILENO, &rights) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit rights for stdout");
  +	if (cap_rights_limit(STDERR_FILENO, &rights) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit rights for stderr");
  +
  +	/* Required for isatty(3). */
  +	cmd = TIOCGETA;
  +	if (cap_ioctls_limit(STDIN_FILENO, &cmd, 1) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit ioctls for stdin");
  +	if (cap_ioctls_limit(STDOUT_FILENO, &cmd, 1) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit ioctls for stdout");
  +	if (cap_ioctls_limit(STDERR_FILENO, &cmd, 1) < 0 && errno != ENOSYS)
  +		err(1, "unable to limit ioctls for stderr");
  +
  +	if (cap_enter() < 0 && errno != ENOSYS)
  +		err(1, "unable to enter capability mode");

No one would dispute that capsicum is more capable but is significantly more complex. Pledge trades finer control over capabilities for the ability to have a "work or die" usage model. Capsicum requires that you be aware of all the potential failure cases and account for them.

The capsicum diff [to tr] required the following ...

This is a slightly out of date example. We've since added simplifying wrappers for stdio.

The current equivalent of if pledge("stdio", ...) / err is:

    if (caph_limit_stdio() < 0 || (cap_enter() < 0 && errno != ENOSYS))
      err();

Some examples: https://reviews.freebsd.org/D8307

a "work or die" usage model

This is an option (or will shortly become an option) in capsicum.

Go (golang) is a great language for web applications and has comparatively small syscall coverage making it easy to sandbox with seccomp(2). It also has most of the protections of a fully managed language, makes making raw syscalls easy, and can be used without libc. If you don't use cgo or SWIG (pure Go and Go assembly are fine), building statically linked pure Go binaries without libc is just a couple of commandline flags. If you don't import the net package or a few other problematic packages, no commandline flags are required.

Apart from the 'easy to sandbox' (also debatable, as that depends way more on the functionality of the application than on what it is written in, but let's ignore that) does that matter much? pledge isn't only, or even primarily, a defense against you accidentally making syscalls you don't want to make, but a defense against malware that, having invaded your application's process, attempts to make such syscalls pretending to be you. That's code you didn't write, making the programming language choice moot.

Not really. An effective sandbox is restrictive. Managed languages tend to use a more limited set of system calls than non-managed languages because most libraries don't make any system calls of their own. The Go runtime and standard library use a more limited set of system calls than most alternatives, so a more limited set of sandbox filters are required.

Injected instructions are more likely to invoke their own system calls, so you are more likely to catch it if you have a more restrictive set of filters.

Does pledge(2) still enable its simple programming interface by allowing certain default actions based on a filesystem hierarchy layout, statically defined in the kernel/libc/somewhere? The first presented versions of tame(2) had this iirc.

The difference between pledge and seccomp is not just a matter of fine-grainedness. There's some of that, but I'd say there's also a difference in philosophy: sandboxing resources versus sandboxing kernel attack surfaces.

At one end of the spectrum is the macOS sandbox, which pretty much only restricts how the process is allowed to interact with the outside world. It's not actually simplistic like the article claims; that's just the public API. If you look at the raw sandbox profiles, which Apple writes for daemons and such, it's quite fine-grained: sandbox profiles can specify which paths can be read and which can be written (with an arbitrary number of allow/deny rules, each of which can match on an arbitrary regular expression), which network ports can be opened or listened to, which preferences can be read or written, which IPC services can be accessed, and so on... there are a ton of categories. If you're on macOS, look in /usr/share/sandbox and /System/Library/Sandbox/Profiles to see what they look like. However, sandboxing only occurs when a given syscall's kernel implementation explicitly calls for it, and even the most locked-down process can access hundreds of syscalls and Mach kernel IPC calls, which based on their intended purpose should be harmless. And most of them really are harmless, but all it takes is a small oversight in one of them for an attacker to potentially corrupt memory in the kernel and gain control over the system. *

At the other end is Linux seccomp, which is designed to allow minimizing kernel attack surface. Chrome's renderer processes only get access to a tiny set of syscalls, and even the arguments to the syscalls are locked down, corresponding as closely as possible to what the process actually uses. (This is possible in part because Chrome has an unsandboxed master process that handles things like reading files for it. The renderer sandbox doesn't even allow open(2).) Thus Chrome is protected from most vulnerabilities in the Linux kernel, because there's just no way to get to the buggy code in question from within the sandbox. This isn't perfect: I've found multiple Linux kernel bugs (only one exploitable so far) that are accessible from the sandbox. And of course it doesn't make Chrome immune to privilege escalation, since attacking the kernel directly isn't the only option; IPC communication with the master process is a much larger attack surface. But that's basically unavoidable, and the situation for Chrome is still a big improvement over other operating systems. Unfortunately, as the article says, it takes quite a lot of work to adapt to new applications.

OpenBSD pledge seems somewhere in between. Unlike the other two, I don't have personal experience using it, but based on the manpage - an empty "promises" set restricts the process to _exit(2), which like seccomp should protect against kernel flaws. However, if you supply "stdio", suddenly the process gets access to 69 system calls, which is not terrible (many of the calls in the set are very basic and unlikely to contain bugs) but not as minimal as one might want. There are a bunch of random functionality lockdowns, which is good - for example, ioctl operations are locked down, "setsockopt(2) has been reduced in functionality substantially"... on the other hand, the promise categories generally seem more aligned to 'resources the program might want to access' than 'kernel API surface the program might need to use'.

Overall, definitely not bad, and I'd like to see something comparable on Linux, but I'd be more comfortable if OpenBSD also supported a more fine-grained sandbox.

* (Okay, that's a little unfair to macOS, since there are some sandbox filters that lock down kernel attack surface, such as the ioctl filter and the IOKit filters - the latter of which has been tightened over time. But that still leaves a ton of surface exposed.)

Would you say Chrome is more sandboxed on Linux due to seccomp than on Windows 10?

I'm confused about what exactly 'sandboxing' entails here. Seems to be limiting syscalls and file system interactions. But what about process heap and cpu usage? Are these handled by either seccomp or capsicum?