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

People hacking servers don't need 4 exploits, but hacking servers is still difficult relative to hacking clientside code, because servers (a) have a more limited attack surface than clients and (b) are less performance-sensitive and thus can rely on memory-safe languages.

Docker and seccomp-bpf are techniques for sandboxing server applications, and they're useful, but they run into the same problem as sandboxing any complex system: the privilege to do many of the things the application ordinarily does --- writing a row in a database table, for instance, or creating a new queue entry --- can unpredictably result in privilege escalation.

The techniques you need to apply to make sure that basic application actions don't escalate privileges are largely the same as the ones you'd take to ensure the application doesn't have bugs.

Don't get me wrong: I think more and more applications will take advantage of serverside sandboxes, to good effect. But I don't think it's going to be a sea-change for security, and I don't think it's valid to compare the "4-exploit chain" needed for Chrome to the situation in a complicated web application.




I don't know docker should be considered security sandboxing. From https://docs.docker.com/engine/security/security/ :

    Running containers (and applications) with Docker
    implies running the Docker daemon. This daemon 
    currently requires root privileges, and you should 
    therefore be aware of some important details.


Docker definitely doesn't follow least privilege. If it were least privilege, then the Docker daemon WOULDN'T EVEN EXIST.

For example, Chrome's sandboxing tool (minijail I think) and systemd-nspawn are NOT DAEMONS. They just set the process state and exec().

Docker is sloppy as hell from a security perspective. It is indeed embarrassing that they mention it in this paper.

Docker has also enshrined the dubious practice of dumping an entire Linux image into a container, and then installing a bunch of packages from the network on top of that.

And now you need a "container security service" as mentioned in the article. How about you just understand what your application depends on, rather than throwing the whole OS plus an overestimation of dependencies in there?


I see your point, but I would say two things:

1) You might be underestimating how far a typical server configuration is from least privilege. It's true that you need to write to database tables or a queue service for the app to work, but a typical configuration has the capability to do hundreds or thousands of other things that are not necessary for the app.

If you have a PHP app running inside a Apache process, how many system calls are needed? What about PHP as a FastCGI process under nginx? Linux has 200+ system calls, and I'm sure the number is a small fraction of that.

What about the privileges for connecting to local daemons? Most people are dumping huge Linux images into Docker and then installing tons of packages by default. Last time I checked, apt-get install will START daemons for you.

It takes some work to figure out what privileges a given application needs, and that's probably why people don't do it. But I would contend that much less hard, and much more bang for the buck than a lot of the techniques mentioned in this paper.

2) You might be underestimating diversity of privileges needed for different application components ("microservices" if you will). For example, in distributed applications I've dealt with, the auth code doesn't need to talk to all the same back ends that the normal application logic does. If it lives in a separate process, which is a good idea for a number of other reasons, it can have different privileges than the rest of the application.

In any case I view this as a kind of "walk before you run" type of thing. If you can't even figure out what privileges your application needs, how are you going to get programmers to add pre- and post- conditions, and apply symbolic execution and techniques like that? The paper sounds absurd and divorced from the realities of software development.

Now that I read the paper, they do devote just 2 pages to "containers and microservices" (which are weirdly buzzword-y terms for a traditional practice). It still seems unbalanced to me.




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

Search: