Shared memory: I believe many if not most simpler applications don’t use it or at least can live without it. Despite being simple, they are frequently exploitable and have to handle untrusted input. Consider tools like file(1) or pretty much any kind of “parse and transform” application.

“The claim “only fork() and memcpy()”: I might have picked that line from /. or another article. Sorry for attributing it to you.

“Considering that all machines have only single-core CPUs,”: What I meant was “What if I only use machines with single-core CPUs?” In fact I do and a lot of infrastructure where CPU power is not very important does too.

“.. the fix appears rather trivial”: That’s certainly exaggerated but I thought of people who are already familiar with the kernel code. I believe the reason nothing happened is mainly that systrace is only maintained by a single person namely Niels Provos and somehow systrace didn’t take-off at all, maybe because it’s complex to configure. Also having to use wrappers is somewhat awkward. People probably just want to apply some restrictions to (application,user) in a central database and the kernel should handle the rest similar to veriexec. There are certainly many usability issue with systrace but then again, if it was reliable, it would still perfect for quite a lot of applications. The question here is also, what’s the alternative? A VM for each application or process would be rather heavy on the CPU and probably just as difficult to configure.

However, I have some idea how the current systrace implementation can still be useful and reliable - not in all - but many real-life relevant cases. An obvious problem are syscalls that use pathnames or socket structures as parameters. In the systrace profile you would simply disallow all of them. The systrace executable would replace the relevant function calls with wrapper functions as in the good ol’ LD_PRELOAD hack. So “open()” would be linked to “systrace_open()” and so on. The actual parameters are send over a unix domain socket to the systrace wrapper (or daemon). The receiving process can identify euid/egid/uid/gid/pid and the pathname of the executable that created the process, so systrace can locate the policy that will rule the request. If it’s granted, systrace calls open() with supplied parameters and passes the file descriptor back over the unix domain socket (an IPC technique known as “file-descriptor passing”). The result code and errno are passed in the same response. The file descriptor number (result code) is of course pointless in this case but matters for stat() and such.

I think this would work for fine-grained access control to the filesystem and sockets.

(1) “None of my policies mention minherit(), so it’s not allowed and apparently not used by any of my traced application.”

The use of minherit() is simply an example — there are many, many ways to set up shared memory between two processes in most UNIX systems, from inheritable mmap()’s, explicit shared memory, memory-mapped files, rfork()/clone(), to threading. Shared memory has been a critical part of the UNIX design for 20+ years, and, combined with parallelism/concurrency, is all that is required in order to exploit these races.

(2) “The claim “only fork() and memcpy()” seems not quite true.”

I can’t find this claim in the blog article, paper, or presentation. Certainly, all my examples make use of other system calls in order to set up shared memory, which is a widely available and heavily used facility; I also manipulate the scheduler process priority to make exploits on UP more successful, which is not strictly necessary but is helpful.

(1) “Considering that all machines have only single-core CPUs, is systrace really broken in this case?”

I think this assumption comes with two false premise:

First, the vulnerability does affect single-core CPUs, as I illustrate in the paper. It just turns out to be even more effective on multi-core.

Second, I would disagree with “all machines have only single-core CPUs”; hyper-threading/SMT, SMP, and multi-core have become widespread, and from commodity server-class boxes shipped 4+ years ago, to the 2-core notebook I got 2+ years ago, to multi-core embedded hardware that’s widespread in networking and telecommunications. The brave new world of parallelism is here in force, and here to stay.

(2) “.. the fix appears rather trivial”

The fix requires significantly rewriting the kernel memory copying code, or, more cleanly, the system call code, and despite suggestions that it would shortly be fixed for the past six+ years since I reported the vulnerability, it still hadn’t been fixed in any of the systems I looked at. Keep in mind also that copying only addresses one half of the problem. Per my comments in the paper about message passing: by moving to true message passing and offering atomic argument access, syntactic races are addressed, but not semantic races, which are inherent to software composition using wrappers.

(3) “Isn’t it still useful…?”

I’ve never said that systrace isn’t useful, just that it is highly vulnerable to a certain class of attacks if used for sandboxing. If your use of systrace does not involve paths, socket addresses, etc, in its policy controls, or if the use isn’t security related, then it presumably not “vulnerable”, although it might be subject to functional race conditions that might well be considered bugs. I have never advocated for the removal of systrace from NetBSD, only that it be properly documented as either a system not appropriate for general-purpose sandboxing as it has been advertised, or that the constraints of sandboxing be properly documented.

thanks for your interest and comments
Robert Watson

I could imagine that systrace is overkill for this purpose but I’m not aware of an existing alternative. I have always considered it as awkward and a design flaw that Unix with all its filesystem security and idea of privileges, provides absolutely no tool to prevent access to the network except for low-level network functions like raw sockets.

Some firewalls can map rules to users and groups but that’s far too coarse even requiring awkward setgid/uid tricks for effective use in practise.

Maybe I’m missing something but I don’t even see, why it hasn’t been fixed. In fact, systrace has been removed from NetBSD albeit the fix appears to be rather trivial. That is systrace needs to know how and which parameters are passed to each single syscall anyway and I don’t understand what’s so difficult about packing/unpacking the parameters at the same time. Copying costs performance of course but as long as it’s much faster than emulation - few programs spent more time with syscalls than userland code - there is not really a performance issue either. Basically, as far as I grasp this, there is absolutely nothing wrong with systrace as a concept. It’s just broken due to an implementation choice that makes it “rather faster than safe”.

your host is constantly attacking my server. I am sure this is because you just don’t care and not due to malevolent actions from your part. Please don’t shut it down and don’t ever be fucked.

Another problem with systrace is that that it’s difficult to know all legitimate code paths a program will take. That might be acceptable when using it on client applications such as a web browser. If you were running your web browser under systrace, and willing to put up with the annoyance of running into new code paths now and then, you would arguably be more secure than someone next to you not running systrace. The reason is because use of systrace is not very common, and most exploits don’t implement the systrace attack. The attacker might not know why his payload failed to run properly. He might not care if he’s out of quantity and not just you. But on the other hand, you might not realize that you were attacked at all. Maybe you just ran into another case of bad systrace policy, turn off automatic enforcement and hit the malicious site again.

Thanks,

Robert Watson